Context control mechanism for data executed in workflows of process, factory-floor, environmental, computer aided manufacturing-based or other control system

ABSTRACT

The invention provides improved methods and apparatus for workflow editing. Such methods and apparatus permit, for example, user-defined and/or other tasks to be combined in any combination or combinations to specify a workflow. The tasks can be linked for direct, serial processing and/or for conditional processing that includes branching and/or looping. The invention also improved methods and apparatus of workflow definition and processing with extensible actions. The invention provides, further, improved methods and apparatus for workflow definition and processing which utilize workflow variables for communication of data and control information among tasks within a workflow. The invention provides, still further, improved methods and apparatus of workflow definition and processing with enhanced messaging. The invention provides, still yet further, improved methods and apparatus for workflow definition and processing which permit definition of hierarchically enumerated data types and for for definition of “plans” to collect, e.g., for storage, data such as the aforementioned hierarchical data types.

BACKGROUND OF THE INVENTION

[0001] This application claims the benefit of filing of U.S. ProvisionalPatent Application 60/372,770, filed Apr. 15, 2002, and entitled METHODSAND APPARATUS FOR WORKFLOW DEFINITION AND PROCESSING, the teachings ofwhich are incorporated herein by reference.

[0002] The invention pertains to digital data processing and, moreparticularly, by way of non-limiting example, to automated workflowdefinition and processing. The invention has application, for example,in process control, environmental control, computer aided manufacturing,and other industrial and non-industrial applications.

[0003] Automated workflow processing is increasingly common in today'smanufacturing plants. Conventional solutions provide generalcapabilities for interfacing plant equipment to identify events and takespecific responsive actions. However, those solutions provide for onlyrudimentary workflow definition and require special-purpose programs tomodel plant operations of complexity. The conventional solutions,moreover, provide only limited interfaces, accepting data from andoutputting data to only specific hardware devices and softwareapplications.

[0004] This runs counter to modern trends, wherein plant owners—and,more generally, all those who own or run process control, environmentalcontrol, computer aided manufacturing, and other industrial andnon-industrial applications—may wish to “mix and match” hardware devicesand software solutions. Thus, for example, different areas of the plantfloor and, certainly, of an enterprise as a whole may use differentprocess control, environmental control, computer aided manufacturing,and other industrial and non-industrial equipment. The same is true ofsoftware (whether it be for control, “back office” reporting andanalysis, and/or other applications) used on the plant floor and/or bythe enterprise.

[0005] Significantly, this also runs counter to a trend for increaseddata distribution and visibility. Continuing the above example, thosewho own or run process control, environmental control, computer aidedmanufacturing, and other industrial and non-industrial applications, maywish to distribute data among different areas of the plant floor and/orwithin the enterprise as a whole, regardless of any existing diversityof hardware and software used. They may wish to do this to improvecontrol, as well as reporting and analysis, on the plant floor and/or bythe enterprise.

[0006] An object of this invention is to provide improved digital dataprocessing systems and methods.

[0007] Another object is to provide such systems and methods as aresuited to workflow definition and/or processing.

[0008] A further object is to provide such systems and methods asprovide increased flexibility and workflow modelling processing overconventional systems.

[0009] A still further object is to provide such systems and methods asfacilitate the mixing and integration of hardware devices and/orsoftware solutions, e.g., whether for improved control, reporting,analysis, or otherwise, on a plant floor, in an enterprise, orotherwise.

[0010] Yet still another object of the invention is to provide suchsystems and methods as facilitate data distribution and visibility,e.g., among hardware devices and/or software solutions, whether ofdiverse varieties or otherwise.

SUMMARY OF THE INVENTION

[0011] These are among the objects attained by the invention whichprovides, in one aspect, improved methods and apparatus for workflowediting. Such methods and apparatus permit, for example, user-definedand/or other tasks to be combined in any combination to specify aworkflow. The tasks can be linked for direct, serial processing and/orfor conditional processing that includes branching and/or looping.

[0012] Related aspects of the invention provide such methods andapparatus as permit third-party (or unrelated) software applications tobe invoked as tasks, with their respective contexts defined byenvironmental variables, e.g., which are interfaced through anapplications program interface (API).

[0013] Further aspects of the invention provide such methods andapparatus which accept and process factory-floor or other processcontrol, environmental control, computer aided manufacturing, and otherindustrial and non-industrial application data, regardless of itssource. Related aspects of the invention provide for enhanced definitionof data sources, data sinks and other tags.

[0014] Still further related aspects of the invention provide suchmethods and apparatus wherein workflow editing is performed graphically,e.g., using panes that are organized hierarchically or otherwise. Yetstill further aspects of the invention provide for definition of theworkflow utilizing a graphical programming metaphor. Related aspects ofthe invention provide for graphical definition of information-flow amongtasks and to/from other applications or devices.

[0015] Other aspects of the invention provide improved methods andapparatus of workflow definition and processing with extensible actions.Such methods and apparatus permit user definition of workflow tasks,e.g., using the graphical programming metaphor or otherwise. Thisincludes, by way of non-limiting example, interfacing legacy softwaresystems and databases.

[0016] Related aspects of the invention provide such methods andapparatus in which the actions conform to a component object model (COM)application program interface (API). That interface can define portionsof a third-party application context required for task implementationand can provide mechanisms for communication of that information.

[0017] Extensible actions according to some aspects of the inventionpermits a workflow to interface with components and subsystems not partof the workflow system. This is done by permitting the workflow toinstantiate component object model (COM) components that implement anextended action interface. A component of this type permits a workfloweditor and workflow processing engine to interrogate the component forinput and output arguments and other properties, as well as to cause thecomponent to execute. The extended action interface provides a portalthrough which the workflow can give information to, and acquireinformation from, external systems.

[0018] Related aspects of the invention provide methods and apparatus asdescribed above in which the input and output argument sets of such acomponent comprise a portion of an overall workflow context. An actioncan be executed with the input argument contexts and, upon return fromthe extended action component, entries in the output argument contextcan be written back to corresponding entries in the overall workflowcontext.

[0019] Still further related aspects of the invention provide suchmethods and apparatus as provide for enhanced communication between atask executing in a workflow processing engine and a third-partyapplication.

[0020] Still other aspects of the invention provide improved methods andapparatus for workflow definition and processing which utilize workflowvariables for communication of data and control information among taskswithin a workflow. Such variables can reflect workflow status,factory-floor or other process control, environmental control, computeraided manufacturing, and other industrial and non-industrial applicationdata and/or other parameters.

[0021] Related aspects of the invention such methods and apparatus asprovide for persistence of the workflow variables, e.g., using XML orother markup languages.

[0022] Still other aspects of the invention provide improved methods andapparatus of workflow definition and processing with enhanced messaging.This facilitates communication with an operator station during workflowexecution.

[0023] Related aspects of the invention provide such methods andapparatus in which both message content and formatting is transmittedbetween a workflow processing engine and an operator interface, e.g.,via a markup language. Related aspects of the invention provide for useof XML and XSL for these purposes. Still further related aspects providefor customizable display of operator interfaces via controls whichexecute style sheets. Yet still further related aspects of the inventionprovide for enhanced transmittal of operator responses to the workflowprocessing engine.

[0024] Still other aspects of the invention provide improved methods andapparatus for workflow definition and processing which permit definitionof hierarchically enumerated data types, referred to below as List PDIs.These can be used to capture multiple levels of data, e.g., for analysisor reporting.

[0025] Related aspects of the invention provide for definition of“plans” to collect, e.g., for storage, data such as the aforementionedhierarchical data types. These plans can include expressions that areevaluated on collection or storage of the data. Such expressions caninclude execution of procedures, e.g., for obtaining or evaluatingfurther data.

[0026] Still other aspects of the invention provide improved methods andapparatus for workflow definition and processing which provide forregistration of third-party and other software applications, e.g., usedby an enterprise, and that facilitate communication with suchapplications. Related aspects of the invention facilitate informationvisibility, e.g., communication of information to/from portals and otherdata display/collection applications, networked or otherwise.

[0027] Still other aspects of the invention provide improved methods andapparatus for workflow definition and processing that utilize a commonevent-driven or other messaging structures, e.g., for transferring datato/from applications and/or operator interfaces.

[0028] Still other aspects of the invention provide improved methods andapparatus for workflow definition and processing that facilitatereal-time gathering, processing, communication and/or reporting of data.

[0029] Advantages of methods and apparatus according to the foregoingand other aspects of the invention are that they facilitate distributionof data upon event occurrence. This can include, by way of non-limitingexample, distribution of distributed control system (DCS) data inreal-tine to transactional software, e.g., executing within or betweenenterprises. It can also include, by way of further non-limitingexample, communication of information necessary for supply chainautomation between a plan and its customers.

[0030] Other aspects of the invention are evident in the claims, as wellas in the text and drawings that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] A more complete understanding of the invention may be attained byreference to the drawings, in which

[0032] FIGS. 1A-1C depict a digital data processing system according toone practice of the invention;

[0033]FIG. 2 depicts a graphical workflow of the type that is created,edited and processed in a system according to one practice of theinvention;

[0034]FIG. 3 illustrates an ActiveX control of the type to supportcommunications between a runtime client and a production engine in asystem according to one practice of the invention;

[0035] FIGS. 4A-D depicts an object oriented class structure used inimplementing a system according to one practice of the invention;

[0036]FIG. 5 depicts steps utilized to populate a data collection in asystem according to one practice of the invention;

[0037]FIG. 6 depicts the life cycle of an action message in a systemaccording to one practice of the invention;

[0038] FIGS. 7-8 depict processing in an event manager in a systemaccording to one practice of the invention;

[0039] FIGS. 9A-9C depict an object oriented class structure supportinginter alia PDIs and collection plans in a system according one practiceof the invention;

[0040]FIG. 10 depicts a database structure supporting List PDIs in asystem according to one practice of the invention;

[0041]FIG. 11 depicts the tree hierarchy of a List PDI in a systemaccording to one practice of the invention;

[0042]FIG. 12 depicts the anatomy of a List PDI in a system according toone practice of the invention;

[0043]FIG. 13 illustrates a simplified standard List PDI of the typeused in a system according to one practice of the invention;

[0044] FIGS. 14A-14C depict graphical user interface screens used inconnection with definition and maintenance of a List PDI in a systemaccording to one practice the invention;

[0045] FIGS. 15-16 depict graphical user interface screens used inconnection with definition and maintenance of collection plans in asystem according to one practice the invention;

[0046]FIG. 17 illustrates a relationship among classes defining theproduction support database and those defining stored procedure items ina system according to one practice of the invention;

[0047] FIGS. 18-19 depict graphical user interface screens used inconnection with collection plan template maintenance in a systemaccording to one practice of the invention;

[0048]FIG. 20 depicts a graphical user interface screen used inconnection with storing information about a PDI in a collection plangenerated from the template in a system according to one practice of theinvention;

[0049]FIG. 21 depicts a graphical user interface editor display,including a sample workflow graphic, in a system according to onepractice of the invention;

[0050]FIG. 22 depicts tables in a database supporting a class structureused in a workflow editor in a system according to one practice of theinvention;

[0051]FIG. 23 illustrates how orders and lot IDs from external systemsare associated with workflows created in a workflow editor in a systemaccording to one practice of the invention;

[0052]FIG. 24 depicts a relationship between workflow elements andextended actions in a system according to one practice of the invention;

[0053]FIG. 25 is a flowchart depicting how workflow variable context ismaintained in a system according to one practice of the invention;

[0054]FIG. 26 depicts a graphical user interface screen used inconnection with workflow variable definition in a system according toone practice of the invention;

[0055]FIG. 27 depicts a relationship of tables used in support ofworkflow variable context persistence in a system according to onepractice of the invention;

[0056] FIGS. 28-29 depict graphical user interface screens used inconnection with user interface (UI) message definition in a systemaccording to one practice the invention;

[0057]FIG. 30 is a flowchart depicting step involved in execution of aUI Message action in a system according to one practice of theinvention;

[0058]FIG. 31 is a UI Message style sheet according to one practice ofthe invention;

[0059] FIGS. 32A-32C is a UI Message schema according to one practice ofthe invention;

[0060] FIGS. 33A-33B is a UI Message template according to one practiceof the invention;

[0061]FIG. 34 depicts an architecture for UI messaging with a thinruntime client in a system according to one practice of the invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENT

[0062]FIG. 1A depicts a digital data processing system 10 according toone practice of the invention. The illustrated system includes one ormore applications 12, 14, 16 of the type commercially available andconventionally used for process, batch, discrete, environmental or othercontrol in manufacturing, utilities or other industries, research orother applications. The applications 12-16 are adapted to monitor and/orcontrol the respective process, batch, environment, and so forth, viasensors and/or control equipment in the conventional manner known in theart. The illustrated system also includes a production engine 18 that iscoupled to applications 12-16 and coordinates data collection,operation, and/or reporting thereby.

[0063] Engine 18 and applications 12-16 may execute on a single digitaldata processing device or multiple digital data processing devices,which may be disposed locally or remotely with respect to one anotherand which may communicate via network or otherwise in the conventionalmanner known in the art. Each digital data processing device mayconstitute a conventional workstation, personal computer, mainframecomputer, controller, microprocessor, embedded processor, “smart” fielddevice or any other hardware/software platform suitable for moduleand/or application execution in accord with the teachings hereof. On anygiven such digital data processing device, the respective engine 18and/or applications 12-16 may execute within a single process though,more typically, they execute in different respective processes.

[0064] Illustrated applications 12-14, referred to as “Appln 0” and“Appln 1,” respectively, have runtime components 12 a, 14 a that operatein accord with information contained in respective databases 12 b, 14 b,proprietary or otherwise, that may be independent or shared betweenthose and other applications in the conventional manner known in the art(as further adapted in accord with the teachings below). Eachapplication 12, 14 also includes an editor (or configurator) that isused in the conventional manner, e.g., to set up and modify therespective database for such functions as are desired by the plantoperator or other personnel. Each additional application 16 cansimilarly include a runtime component, database and editor.

[0065] Those skilled in the art will, of course, appreciate that, perconvention in the art, applications 12-16 may include fewer componentsor more components than those shown in the drawing and described herein.Thus, for example, some application used in systems according to theinvention may include only a runtime component and others may includemultiple runtime components, databases and/or editors, as well as othercomponents.

[0066] Illustrated production engine 18 includes a runtime component 18a—referred to below both as the “event manager” or “productionengine”—that coordinates operation of, data collection for, and/orreporting for applications 12-16. This is governed by workflow(s) andparameters defined in a configuration database 18 b—though, in alternateembodiments these may be hardcoded, e.g., in the runtime component (18a) and/or defined elsewhere. An editor (or configurator) 18 c, whichincludes the Workflow Editor described below, provides a user interfaceand/or otherwise facilitates set up and modification the database 18 band, more generally, the production engine 18.

[0067] The aforementioned operational coordination, data collectionand/or reporting may be effected via coupling between the component 18 a(the event manager) and the applications' respective runtime components12 a-14 a, e.g., utilizing application program interfaces (APIs) orother interprocess communications techniques, as discussed below. Thoughall of these coupling mechanisms are indicated in the drawing by linesconnecting component 18 a with the runtime modules 12 a-14 a anddatabases 12 b-14 b, those skilled in the art will appreciate that feweror additional mechanisms may be employed as well consistent with theteachings below.

[0068] In the illustrated embodiment, further coupling between theproduction engine 18 and the applications 12-16 is provided via theirrespective database components 12 b, 14 b and 18 b. To this end, system18 includes a interpreter 18 d that transfers data between theconfiguration database 18 b and the application's respective databases12 b-14 b. Such transfers may be effected at configuration time, atruntime, periodically, continuously, or otherwise, e.g., in accord withthe teachings below.

[0069] Communications coupling, formatting and/or translation requiredfor each respective database 12 b-14 b is effected by respectiveinterface adapters shown, here, “hanging off” the interpreter 18 d andlabeled A0, A1. In practice, the adapters may be part of (e.g., “hangoff”) the interpreter 18 d and/or the databases 12 b-14 b themselves(and, more properly, respective database managements systems—which may,for example, form part of the respective runtime or editor components 12a, 12 c-14 a, 14 c).

[0070] To facilitate coordinated setup and/or modification of the system10, databases 12 b, 14 b, 18 b, configuration editor 18 c may includeadapters that facilitate direct setup or modification of the applicationdatabases 12 b-14 b, or portions thereof, e.g., via an interfaceconsistent with that provided by editor 18 c vis-a-vis database 18 b,via interfaces consistent with those provided by editors 12 c-14 cvis-a-vis databases 12 b-14 b, or otherwise. As above, the adapters areshown here hanging off the editor 18 c and labeled A0, A1. In practice,the adapters may be part of the editor 18 c and/or the databases 12 b-14b themselves.

[0071] Applications 12-16 are clients of the production engine 18, e.g.,insofar as those applications rely on services or data provided byengine 18 for purposes of setup and/or coordinated runtime operation.The illustrated system includes further clients, here, runtime clients18 e, 18 f that provide for notifications (e.g., alarms), workflow orother status reporting, and/or data collection, e.g., via userinterfaces with plant operator or other personnel. While runtime clients18 e, 18 f can be adapted to interface process or other controlequipment, e.g., in the manner of applications 12-16, in the illustratedembodiment, the runtime clients are more typically adapted to providealarms, notifications and other information to plant personnel and/or toreceive information therefrom, e.g., in addition to or in lieu of suchinformation provided to and/or received from such personnel by theapplications 12-16. More particularly, in one embodiment, the runtimeclient provides for security (e.g., password entry and accessrestriction); data trending; alarm notification; task list entry,editing, history reporting and querying; graphical or other workflowstatus visualization; and workflow state setting (e.g., offline versusactive).

[0072] Overview of Operation and Terminology

[0073] The production engine 18 provides a framework to configure,capture and manage process and production data based on inputs from (andoutputs to) applications 12-16, plant or personnel, and/or process orother control equipment. It also provides for correlating process andproduction data, e.g., to facilitate analysis of the effectiveness of afacility or process. To this end, the engine 18 comprises, inter alia,an event manager 18 a that monitors the equipment or processes, forexample, via communications with applications 12-16 and via interfaces(e.g., through runtime clients 18 e, 18 f) with the plant personneland/or control equipment directly); executes workflows and evaluates anyexpressions defined therein; triggers actions; prompts plant personnelwith or for information; collects data from the applications, personneland/or control equipment.

[0074] As noted above, operation of the event manager 18 a is based onworkflows, e.g., represented in database 18 b. Workflow types include,by way of non-limiting example material workflows (e.g., manipulatingraw materials to produce finished goods), equipment workflows (e.g.,based on a manufacturing resource, e.g., machine, line, cell,exceptions, faults and regular maintenance activities, cleaning,calibration, failures) and supply chain and/or information workflows(e.g., moving information between applications or areas in anenterprise). Workflows can be triggered by multiple machines, withparameters captured automatically from that equipment or manually fromits operators.

[0075] As discussed further below, workflow definitions can includeevent triggers, e.g., process value changes, device inputs, productionstatus changes, resource status changes, messages from otherapplication, or UI messaging. Workflow definitions in the illustratedembodiment also typically include event actions. These can includetransactions (such as start, complete, etc.) in applications 12-16,stored procedures/database actions; set-point downloading; user tasks,such as data collection, downtime reporting, sample registration,production reporting, consumption reporting, maintenance task; operatormessaging (referred to below as User Interface or UI messages); andSCADA alarm actions, such as e-mail, pager, or telephone messages; toname a few.

[0076] In addition to events and actions, a workflow of the illustratedembodiment can include activities, which are defined by one or morerelated actions; transitions, which inhibit the execution of a workflowuntil a condition is met; conditional branches, which allow one branchof activities to executed based on evaluation of an expression; decisionbranches, result in execution of one branch of activities if theevaluation of an expression is true and another branch if false; loops,which execute a executes a series of activities until a condition ismet. Of course, it will be appreciated that workflows may have othercomponents, instead or in addition, consistent with the teachingshereof.

[0077] Workflow definitions in the illustrated embodiment utilizeprocess data items or PDIs. These capture, track and move informationabout the controlled process. PDIs represent an aggregation offunctionality, such as a transaction input, I/O point (or “tag”),process historization, alarming and analysis. Types of PDI in theillustrated embodiment include memory variables/local workflowvariables, I/O and device input, user input, and database I/O. Atruntime, sources of PDI values include tags (or I/O points), informationmanually entered (e.g., via a runtime client), values derived from otherdata, information retrieved from application databases 12 b-14 b,arithmetic and/or logical expressions.

[0078] By way of example, plant equipment such as a packer unit signalsthe production engine indicating that its status has changed to anon-running state. A scheduler operating within the event manager 18 areschedules work otherwise assigned to that unit to other plantequipment, updating a work-in-process module with the new equipmentinformation. Based on the downtime cause reported by the equipment andits' expected duration, the scheduler also reschedules the shop floor toaccount for the lost resource and releases a new schedule to the floor,e.g., via operator messing in a runtime client 18 e, 18 f, concurrentlyupdating application databases 12 b-14 b (and other tables, databases,etc.) that govern operation of the floor equipment. The scheduler alsosignals the runtime components of necessary applications, e.g., 12 a, toreflect transfer of the job and operators to the new equipment.

[0079] Concurrently, the scheduler treats the underlying cause of thenon-running state as an indicator of a maintenance task, to which itassigns a resource—here, a mechanic. It notifies both the mechanic andthe information technology department (and/or other enterprisepersonnel) of the assignment, e.g., via a runtime client 18 f. Thescheduler also messages personnel to have the parts prepared anddelivered to the downed equipment.

[0080] Referring to FIG. 1B, in the illustrated embodiment, theapplications 12-16 include InTrack™ and InSQL™, both commerciallyavailable from the assignee hereof. InTrack™ provides for graphicalrepresentation of a controlled process (and the underlying equipment orother resources). It permits, for example, tracking of production fromraw materials through to finished goods inventory, and can model andtrack critical resources like work orders, materials, productspecifications, work instructions, equipment, people andprocess/analytical data. InSQL™ is an SQL server that provides a commonpoint of access for production information utilized by InTrack,providing for acquisition of production data in real time andintegration of non-real-time, manual or off-line data. Theseapplications share a common database, e.g., 12 b, associated with theInTrack™ product, as well as having independent databases, e.g., anInSQL™ database (associated with the InSQL™ product).

[0081] The runtime component of the InTrack™ application is depicted inFIG. 1B as element 12 a; the database component, as element 12 b; andthe editor (referred to as Model Maker™), as element 12 c. Thecorresponding components of the InSQL™ application are depicted aselements 14 a, 14 b and 14 c. Further applications, depicted in thedrawing by elements 16 a, 16 b, 16 c, can include by way of non-limitingexample the InTouch™ product, which is commercially available from theassignee hereof and which provides a human machine interface (HMI),enabling visualization of control and information resources, e.g.,represented by InTrack.

[0082] Of course, those skilled in the art will appreciate that otherapplications, regardless of whether available from the assignee hereof,can be utilized in addition to or instead of inTrack™, InSQL™, and/orInTouch™. Those applications may be competitive, functional or otherequivalents of the type known in the art amenable or adaptable for usein systems operating according to the teachings hereof. By way ofexample, in place of (or in addition to) the inSQL™ server, another SQLserver may by utilized, as may be a database management system, querysystem or other system capable of querying or otherwise identifyingitems of interest in a database, table or other data collection.

[0083] Also shown in FIG. 1B is the division of configuration database18 b into a configuration database components 18 b′ and one or moreruntime components, here, a runtime “support” database component 18 b″and a runtime “tag” database component 18 b′″. The configurationdatabase component 18 b′ maintains a representation of the workfloweditable by editor (or configurator) 18 c. The runtime components 18 b″and 18 b′″ maintain representations of the workflow uploaded from theconfiguration component 18 b′, as well as of operational parameterstaken from the other application databases, e.g., 12 b, 14 b, and 16 b.Thus, for example, support database component 18 b″ can maintain arepresentation of event triggers, event actions, activities,transitions, conditional branches, decision branches, loops, and soforth that make up a workflow. Tag database component 18 b′″ on theother hand, for example, maintains a representation or listing of I/Oports, memory addresses and other tags potentially implicated by theworkflow.

[0084] The runtime components 18 b″ and 18 b′″ of the configurationdatabase 18 b are generated by the interpreter 18 d and/or by ancompilation/upload component (not shown). This can include compilinginto a suitable runtime representation for component 18 b″ the graphical(or other) representation of the workflow maintained in configurationdatabase 18 b′. It can also include resolving references to tags andother parameters in the configuration representation so that they can beproperly accessed at runtime by the production engine.

[0085] According to one practice of the invention, workflows in theconfiguration database 18 b′ are maintained in “disabled” or “enabled”states, as determined by the operator, e.g., using a menu or otheroption in editor 18 c. In a preferred practice, the interpreter 18 dand/or compilation/upload element upload to the runtime databases 18 b″and 18 b′″ only configuration database 19 b′ workflows that are in the“enabled” state.

[0086] Likewise, according to one practice of the invention, workflowsrepresented in the runtime databases 18 b″ and 18 b′″ are maintained in“offline”, “active” and “running” states. Workflows in the offline stateare not executed or “evaluated” by the event manager 18 a, while thosein the active state are amenable to such execution. Workflows currentlybeing executed by the event manager are referred to as running.

[0087] Generation of the tag database 18 b′″ can be accomplished, forexample, by creating a indexed, trees or other accessible compilation oftags suitable for access by the production engine 18 during execution ofthe workflow represented in database 18 b″.

[0088] Although the illustrated embodiment utilizes separate databases18 b′-18 b′″ to maintain the configuration versus runtimerepresentations of workflows, alternate embodiments utilize a singledatabase (or set of databases) for both configuration and runtime.

[0089] In some embodiments, the production engine accesses the tagdatabase 18 b″ directly. In other embodiments, a tag database server(not shown) serves as an interface between the production engine 18 andthe database 18 b″. One such server is commercially available from theassignee hereof as part of its inTouch™ software package.

[0090] With further reference to FIG. 1B, the production engine 18 ofthe illustrated embodiment includes an application server component thatprovides an interface between the production engine and one or more ofthe databases 18 b′″, 12 b, 14 b, 16 c. The application server, whichcan be packaged separately from the event manager 18 a or other runtimecomponents, support multiple access by simultaneous clients to thesedatabases, e.g., thus permitting the production engine to access thedatabases for purposes of workflow execution while, at the same time,permitting the applications 12-16 to access respective ones of thosedatabases to carry out application-specific tasks (e.g., in response tonotifications from the production engine).

[0091]FIG. 1C depicts an architecture of the system 10 according to onepractice of the invention. To facilitate review of the drawing, likeelement designations are used in FIGS. 1A-1C to indicate likecomponents. A client application further to those described above aselement 12-16 is identified by the designations 16 a, 16 b, reflectingthe utility of the system 10 with a variety of applications. Here, thatapplication is a statistical process control package, SPC Pro, availablefrom the assignee hereof, though, it will be appreciated that otherapplications, regardless of whether for statistical process control, canbe used in addition or instead. Process or other control equipment withwhich the applications 12-16 is designated as “Control System” in thedrawing.

[0092] Communications between the elements and components of FIG. 1C maybe effected in an conventional manner known in the art, including, butnot limited to ActiveX, Microsoft™ COM (component object model), COM+,DCOM, OLE, JAVA, OpenDOC, Netscape Live-Connect. In the embodimentrepresented in FIG. 1C, specific such communications mechanisms areidentified in the lines connecting several of the elements andcomponents. Thus, for example, COM is used for communications betweenthe event manager 18 a and the runtime clients 18 e, 18 f, as well asbetween the event manager 18 a and a configuration manager 18 g. OLE isused, by way of further example, between the inTrack application 12 aand each of the configuration manager 18 g and the event manager 18 a.

[0093] In the illustrated embodiment, further communications mechanismsare used as well. Thus, a communications protocol and, moreparticularly, and applications program interface (API) defined under theinTouch External Database Access (IDEA) software package commerciallyavailable from the assignee, is used to support communications with theinTouch application (which as noted above serves, e.g., as the tagdatabase 18 b″ server). Any other mechanism, commercially available,proprietary or otherwise, supporting such access and, more generally,providing communications coupling among and between the elements may beused in addition or instead.

[0094] Likewise, the protocol (and API) known as SuiteLink™ available ininput/output servers commercially available from the assignee is used tosupport communications between applications available from the assignee(e.g., inTouch, inSQL, and inTrack) and the devices of the controlsystem. Those servers are identified collectively in the drawing as an“IO Server.” Again, any other mechanism, commercially available,proprietary or otherwise, server-based or otherwise, supporting suchaccess and, more generally, providing communications coupling with thecontrol system may be used in addition or instead. These same or othercommunications mechanisms can also be used to provide communicationscoupling between the control system and the real time clients 18 e, 18f.

[0095] Production Engine

[0096] Overview

[0097] The production engine 18 includes two components, a configurationclient and an interpreter, to enable the user to enter data into asingle point. The configuration client, which comprises theconfiguration database 18 b and editor 18 c, allows the user toconfigure a process data item (PDI). Each such data item represents atag and particularly, in the illustrated embodiment, a tag from theInTouch application, e.g., 12. The data item may also represent a tagfrom the InSQL application if any of the historization attributes areselected. Of course, those skilled in the art will appreciate that thedata items may represent tags from other application instead or inaddition. Once the tag is configured and saved, the aforementionedinterpreter is executed which transfers the appropriate attributes tothe InTouch tag database 12 b and InSQL database 14 b.

[0098] The configuration client permits security groups, users andassociated passwords to be created. Once the user information is saved,execution of the interpreter transfers the security information to theInTrack application 12.

[0099] The configuration client provides a mechanism for defining anobject called a collection plan. The basis of the collection plan is adata collection from one of the applications 12-16, here, the InTrackapplication 12. When the user saves the collection plan and runs theinterpreter, an automation server is used to create the data collection.Machine and location attributes are available on a collection plan andother objects within production engine. If these attributes arespecified they are created within the underlying application, here,InTrack, after running the interpreter. The following default items arecreated in that application from the interpreter: Default machine typesPE Machine and PE Line.

[0100] In a typical implementation of one of the applications 12-16 (andparticularly, for example, the InTrack application 12), a clientapplication is developed for a shop floor operator. The clientapplication varies but characteristically takes input from the user orgathers information from a control system. These values are used incalls to the automation server or any automation server of anotherapplication. The production engine utilizes a set of predeterminedactions that encapsulate some of the common transactions. The useroperates the configuration client (e.g., database 18 b and editor 18 c)to create instances of these actions to map control system values viaPDIs to the action's parameters. Execution of the actions as part of aworkflow replaces the capability provided by the custom scripting orcustom applications.

[0101] A client of the production engine provides on-demand graphicalreports and basic input mechanisms. The client can contain a screen toallow user input into collection plans. Collection plans can be executedon demand or appear to the user by request of engine. A series ofreports are also available via buttons on the screen.

[0102] Extended Actions

[0103] To understand how automation of manufacturing processes involvingthe interaction of people, equipment, applications, time and externalhardware events is facilitated by the production engine 18, it will beappreciated that actions used in the production engine can literally becalls to a limitless range of software. Tasks required of theapplications 12-16 are wrapped in COM wrappers, which conforms to adefined interface. The simple COM wrapper conforming to a pre-definedinterface enables the configuration client to detect the wrapper'spresence on the machine. Once detected the user can create instances ofthat action for execution in a workflow. The fact that the user can mapthe new action's parameters to workflow context variables or controlsystem I/O points (PDIs) facilitates interaction of production engineactions and applications 12-16.

[0104] For example, to execute actions of a new application, theprogrammer can wrap that application's APIs in a component with theextended action interface. Once selected from the configuration clientand configured, interpreted, and also installed on the applicationserver, it is available for execution by the engine and thus can utilizeinformation from previous actions via parameters the same way internalproduction engine actions use the variables.

[0105] This ability to add programmatic interaction between anyapplication 12-16 (or external software or hardware) relies on use ofone of two interface methods:

[0106] GetArguments([out] BSTR InputArgsXmlSpec, [out] BSTROutputArgsXmlSpec)

[0107] GetArguments( . . . ) is a method that, when implemented by theaction provider, provides an XML string that contain elements with aname attribute (the name of the argument), a data-type attribute (MSXMLdata types) and a value for the element (which is set to an unused valuein this situation). One of these strings defines the necessary inputargument list while the other describes the output argument list, whichwill be generated. These arguments define the argument lists of theExecute( . . . ) method.

[0108] Execute([in] BSTR InputArgsXmlCollection, [out] BSTROutputArgsXmlCollection)

[0109] The Execute( . . . ) method requires two parameters: the inputargument list and the output argument list. These argument lists are XMLstrings as described above and contain the values appropriate for themethod call and the return from the method call, respectively.

[0110] The workflow editor 18 c′ allows greater control of taskdefinition and interaction. If operator input is required for an action,a prompt message can be added into the workflow and automatically sentto the designated operator to retrieve the input. Once the operatorenters the input it is returned to the engine. That information isavailable for use in subsequent actions of the same workflow viaworkflow context variables.

[0111] Instances of actions created in the production engine'sconfiguration client, which use PDIs as parameters, implement theinteraction with the control system. Through the use of workflowvariables described previously, it allows the activities of theequipment to be intertwined with the activities of the user.

[0112] The production engine 18 provides a user interface that allowsthe operator to select a particular instance of a workflow and visuallysee the action currently being performed. It also gives informationabout the status of the workflow. The operator has the option to do suchthings as:

[0113] Enable or disable a workflow—allows the workflow to be removedfrom the runtime system if disabled or added to the runtime system whenenabled.

[0114] Pause/continue the workflow—if a workflow is running the operatorcan choose to pause after the completion of the current action.

[0115] A further understanding of the relationship between controlapplications 12-16 and workflow extended actions may be attained byreference to the following discussion of the automated generation of anextended action for e-mailing. Sample code is provided within commentsin each of the methods shown.

[0116] In the discussion that follows, “activity” refers to an atomicunit of work. An activity is the smallest unit of work in a workflowthat can exist either alone or in combination. For our purposes thecombination of activities creates a workflow. This single unit of workis referred to elsewhere herein as an “action”. “Extended Action” refersto a component, conforming to an aforementioned COM interface containingone or more activities. These activities are displayed in the WorkflowEditor for use in a workflow.

[0117] After an interface is named and specific actions associated withit are identified, a class is created. The newly created class can beopened in an applications development tool (here, Visual Studio C++) andthe interface (here, IExtendedAction) expanded, as presented, by way ofnon-limiting example, in FIG. 24.

[0118] The sample code shows parameters being created for sending anEmail: ImsUtil::IEAParametersPtr eaparams; hr = eaparams.CreateInstance(_uuidof(ImsUtil::EAParameters)); if (SUCCEEDED(hr)) { // the exceptionhandling is new. Errors must be propagated to the engine in a particularformat. // It is YOUR responsibility to provide proper error messagesfor workflow debugging. BEGIN_EXCEPTION_HANDLER( ) // Add a parameter byspecifying it's name, type, direction, presence, description and adefault value // this first parameter is the NEW map parameter typeeaparams->InsertCollection(L”ToList”, ImsUtil::eln, ImsUtil::eRequired,L”Recipient list”, 0); eaparams->Insert(L”From”, ImsUtil::eString,ImsUtil::eln, ImsUtil:: eRequired, L”Sender”, L””);eaparams->Insert(L”Subject”, ImsUtil::eString, ImsUtil::eln, ImsUtil::eRequired, L”Message Subject”, L””); eaparams->Insert(L”Message”,ImsUtil::eString, ImsUtil::eln, ImsUtil:: eOptional, L”Message”, L””);eaparams->Insert(L”Status”, ImsUtil::eString, ImsUtil::eOut, ImsUtil::eOptional, L”Message sent status”, L””); // again this is the end of theerror handler for this section of codeEND_EXCEPTION_HANDLER(EXCEPTION_COM, 1009, L”Error inserting parametersinto EAParameters component.”) // Place this xml definition of theparameters to the Execute method in the return BSTR* parameterBEGIN_EXCEPTION_HANDLER( )  eaparams->PersistToXML(ParamInfo);END_EXCEPTION_HANDLER(EXCEPTION_COM, 1003, L”Error de-materializingparameters from EAParameters component.”)  }  else  THROW_EXCEPTION(EXCEPTION_COM, 1004, L”Error creating instance ofEAParameters component.”)   END_EXCEPTION_HANDLER(EXCEPTION_COM, 1004,L”Error creating instance of EAParameters component.”)

[0119] Each of the parameters (input and output) can be decoded from theconverted XML string: // declare autoptrs to the input and outputparameter containers ImsUtil::IEAParametersPtr inparams;ImsUtil::IEAParametersPtr outparams; // declare return values forCreateInstance HRESULT inphr; HRESULT outhr; // declare a CComVariant tohold the value of a parameter CComVariant v; // Create parametercontainer objects inphr = inparams.CreateInstance(_uuidof(ImsUtil::EAParameters)); outhr = outparams.CreateInstance(_uuidof(ImsUtil::EAParameters));  // New error handlingBEGIN_EXCEPTION_HANDLER( ) if (SUCCEEDED(inphr) && SUCCEEDED(outhr)) {BEGIN_EXCEPTION_HANDLER( )    // Load the inparams container from theinput parameters BSTR    passed to Execute inparams->InsertFromXML(InParams); END_EXCEPTION_HANDLER(EXCEPTION_COM,1005, L”Error materializing EAParameters component from inputparameters.”) //*+++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++ // USED FOR EMAIL EXTENDED ACTION SAMPLE // // Thefollowing code shows how to use the InParams and OutParams in the //execution of an Extended Action. Modify to fit your parameterrequirements.  BEGIN_EXCEPTION_HANDLER( ) //Create the Message to sendCDO::IMessagePtr iMsg(_uuidof(CDO::Message)); // Next Load the Fldsobject with the values of the parameters in  inparamsBEGIN_EXCEPTION_HANDLER( ) std::wostringstream oss; int  numitems = 0;BSTR  name = 0; ImsUtil::DataType  dt; CDO::FieldsPtr Flds; Flds =iMsg->Fields;  BEGIN_EXCEPTION_HANDLER( ) if (inparams->Find(L”ToList”,&v)) { ImsUtil::IEAMapParameterPtr tolist; if(SUCCEEDED(tolist.CreateInstance (_(—)uuidof(ImsUtil::EAMapParameter)))) { v.ChangeType(VT_BSTR); // add theelements of the to list to the xml string holding the recipientstolist->InsertFromXML(v.bstrVal); while (tolist->FindByIndex(numitems++,&name, &dt, &v)) { v.ChangeType(VT_BSTR); if (numitems > 1) oss << L”;”<< std::endl; oss << v.bstrVal << std::endl; } if (name)::SysFreeString(name); } else throw ExceptionMessage(o, EXCEPTION_(—)COM, 1008, L”Error creating instance of EAMapParameter component.”); }END_EXCEPTION_HANDLER(EXCEPTION_COM, 1008, L”Error creating instance ofEAMapParameter component.”) // assign the xml string to the mapparameter field Flds->Item[cdoTo]->Value = CComVariant(oss.str( ).c_str()); if (inparams->Find(L”From”, &v)) Flds->Item[cdoFrom]->Value = v; if(inparams->Find(L”Subject”, &v)) Flds->Item[cdoSubject]->Value = v; elseFlds->Item[cdoSubject]->Value = _variant_t(L””); oss.str(L””); numitems= 0; if (inparams->Find(L”Message”, &v)) { v.ChangeType(VT_BSTR); oss <<v.bstrVal << std::endl; } BEGIN_EXCEPTION_HANDLER( ) if(inparams->Find(L”MsgList”, &v)) { ImsUtil::IEAMapParameterPtr msglist;if (SUCCEEDED(msglist.CreateInstance (_(—)uuidof(ImsUtil::EAMapParameter)))) { v.ChangeType(VT_BSTR);msglist->InsertFromXML(v.bstrVal); while(msglist->FindByIndex(numitems++, &name, &dt, &v)) {v.ChangeType(VT_BSTR); oss << (wchar_t*)name << L”: “ << v.bstrVal <<std::endl; } if (name) ::SysFreeString(name); } else throwExceptionMessage(o, EXCEPTION_(—) COM, 1008, L”Error creating instanceof EAMapParameter component.”); } END_EXCEPTION_HANDLER(EXCEPTION_COM,1008, L”Error creating instance of EAMapParameter component.”)Flds->Item[cdoTextDescription]->Value = CComVariant(oss.str( ).c_str()); Flds->Update( ); END_EXCEPTION_HANDLER(EXCEPTION_EXT_ERROR,  1010,L”Error configuring  email message.”) // send the email messageiMsg->Send( ); END_EXCEPTION_HANDLER(EXCEPTION_EXT_ERROR, 1011, L”Errorsending email message.”) BEGIN_EXCEPTION_HANDLER( ) // Add the onlyoutput parameter, Status, to the outparams container outparams->Insert(L”Status”, ImsUtil::eString, ImsUtil::eOut,ImsUtil::eOptional, L”Message sent status”, L”Message Sent!”);END_EXCEPTION_HANDLER(EXCEPTION_COM, 1012, L”Error inserting outputparameters into EAParameters component.”)//+++++++++++++++++++++++++++++++++++++++++++++++++  ++++++++++++++++++++++*/ BEGIN_EXCEPTION_HANDLER( ) // Serialize theoutput parameter containter into the return BSTR* parameteroutparams->PersistToXML(OutParams); END_EXCEPTION_HANDLER(EXCEPTION_COM,1006, L”Error de-materializing output parameters from EAParameterscomponent.”) } else throw ExceptionMessage(o, EXCEPTION_COM, 1007,L”Error creating instance of EAParameters component.”);END_EXCEPTION_HANDLER(EXCEPTION_COM, 1007, L”Error creating instance ofEAParameters component.”)

[0120] A new extended action component created in this way can beregistered with the digital data processor that executes the productionengine 18 and can be used in the workflow editor 18 c′ as describedabove and elsewhere herein.

[0121] Production Engine System Structure

[0122] The illustrated system 10 and, particularly, for example, theproduction engine 18, can be implemented in three nodes: databaseserver, application server and client node. The configuration client(e.g., database 18 b and editor 18 c) may be installed on anyone ofthese nodes. The database server and application server can physicallyreside on the same server, though, this may present resource contentionissues. In the illustrated embodiment, each node utilizes MicrosoftMessage Queue (MSMQ) to communicate events and responses.

[0123] The following is a list of components used in the illustratedembodiment on each node and a brief description of their function:

[0124] Database Server

[0125] Scheduled Event Module (ScheduledEventsXP.dll)—used forcommunicating time based events to the event manager service 18 a

[0126] SQL Stored Procedures for configuration client, cdac,import/export, interpreter, event manager service, security service,display manager, and runtime client.

[0127] Configuration database 18 b′ for configuration data

[0128] Production Support database 18 b″ for runtime data

[0129] Application Server

[0130] Event Manager Service—Event engine for workflow execution.

[0131] Security Manager Service—Validates all user logins

[0132] Application Server Message Queue Monitor Service—mechanism formonitoring and detecting issues with message queue, which are undetectedby message queue.

[0133] GEO—publicly available from Shawn A. VanNess, atxonix@mindspring.com, for evaluation of expressions. Other expressionevaluation software (proprietary or otherwise) may be used instead or inaddition.

[0134] DssManager Application—Makes updates to InTrack based on aresponse or message time out from the runtime client

[0135] Abstraction Client—Toolkit for accessing InTouch tags

[0136] Runtime Client Node

[0137] Active Client ActiveX Control—Mechanism to edit collection planactions and to query data collection information within InTrack

[0138] Queue Arrived ActiveX Control—monitors client's personal messagequeue. The control monitors for a message from event manager 18 aindicating that a new message is on a runtime client common queue thatit is interested in seeing.

[0139] Configuration Client Node

[0140] Workflow Editor—graphical modeling of the workflow

[0141] Configuration Client Executable

[0142] Interpreter—transfer data amongst InTrack, InTouch, InSQL,production engine support database and Config database

[0143] Import utility—import comma separated file containing Configdatabase

[0144] Export Utility—export a comma separated file with

[0145] Standard Message Structure

[0146] In the illustrated embodiment, messages sent are sent to and fromthe production engine 18 and, more particularly, the event manager 18 avia the Microsoft Message Queue, though other messaging systems may beused in addition or instead. The message fields may change contentaccording to the intended message queue. The current message structurefor communication trigger messages is as follows, though other messagestructures can be used instead or in addition.

[0147] Label—Trigger Name

[0148] AppSpecific—Message Type as described below: typedef enum_cmdMsgType { // EventMgr & RTC MSG Types mtNotify = 0,mtCollectionPlan, mtProductionEvent, mtTrigger, mtExpressionResult, //EventMgr Admin MSG Types mtShutdown = 50, mtTraceLevel, // ProductRestart MSG Types mtStartAll = 100, mtStopAll, mtStartComplete,mtStartError, mtStopComplete, mtStopError, mtUpdateStatus,mtSPCProductRestart, mtSPCProductChangeOver, mtError, mtSystemMonitorMsg= 500 } eCmdMsgType;

[0149] Body—Workflow Context Variables—These variables are stored as anXML message of name value pairs.

[0150] The parts of the message described above (Label, AppSpecific,Body) are the actual names of the parts of Microsoft's Message object.

[0151] Message to the runtime clients having the following format:

[0152] AppSpecific—Message Type as described below: typedef enum_cmdMsgType { // EventMgr & RTC MSG Types mtNotify = 0,mtCollectionPlan, mtProductionEvent, mtTrigger, mtExpressionResult,mtUIMessage, // EventMgr Admin MSG Types mtShutdown = 50, mtTraceLevel,// Product Restart MSG Types mtStartAll = 100, mtStopAll,mtStartComplete, mtStartError, mtStopComplete, mtStopError,mtUpdateStatus, mtSPCProductRestart, mtSPCProductChangeOver, mtError,mtSystemMonitorMsg = 500 } eCmdMsgType;

[0153] Label—A bitwise representation of workstations. Bit position 1indicates that workstation #1 can receive the queue message, Bitposition 2 indicates that #2 can receive the queue message. Thismechanism allows a single message to be sent to a workstation group andhave only one workstation actually respond to the message.

[0154] Body—Workflow Context Variables—These variables are stored as anXML message of name value pairs.

[0155] IMS Message Toolkit

[0156] The XML messages used in production engine 18 and, moreparticularly, the event manager 18 a of the illustrated embodiment allhave a common piece—a name and value. A series of class structures isavailable for use by other C++ components. This class structure not onlyexposes the methods required to traverse and extract the pieces ofinformation but also the ability to persist them to a database forbackup. interface IIMSKeyValueMap : IDispatch { [id(1), helpstring(“Addkey/value pair to map container.”)] HRESULT Insert([in] BSTR keyname,[in] VARIANT value); [id(2), helpstring(“Find value of given key in mapcontainer.”)] HRESULT Find([in] BSTR keyname, [out] VARIANT *value,[out, retval] BOOL *found); [id(3), helpstring(“Find value of givenindex in map container.”)] HRESULT FindByIndex([in] unsigned int index,[out] BSTR *keyname, [out] VARIANT *value, [out, retval] BOOL *found);[id(4), helpstring(“Count of the number of key/value pairs in the mapcontainer”)] HRESULT Count([out, retval] unsigned int *count); [id(5),helpstring(“Erase key/value pair associated with key from the mapcontainer.”)] HRESULT Erase([in] BSTR keyname, [out, retval] BOOL*found); [id(6), helpstring(“Clear all key/value pairs from the mapcontainer.”)] HRESULT Clear([out, retval] unsigned int *count); [id(7),helpstring(“Stream the map contents to XML.”)] HRESULTPersistToXML([out] BSTR *xml); [id(8), helpstring(“Write the contents toa table in the DB with the key and value as separate columns.”)] HRESULTPersistToDB([in] BSTR connectionstring, [in] BSTR tablename, [in] BSTRkeycolumn, [in] BSTR valuecolumn); [id(9), helpstring(“Insert thekey/value pairs from XML into the map container.”)] HRESULTInsertFromXML([in] BSTR xml); [id(10), helpstring(“Insert the key/valuepairs read from the DB into the map container.”)] HRESULTInsertFromDB([in] BSTR connectionstring, [in] BSTR tablename, [in] BSTRkeycolumn, [in] BSTR valuecolumn); [propget, id(11), helpstring(“Streamthe map contents to XML”)] HRESULT XML([out, retval] BSTR *pVal);[propput, id(11), helpstring(“Insert the key/value pairs from XML intothe map container.”)] HRESULT XML([in] BSTR newVal); };

[0157] IMS Trigger Toolkit

[0158] Applications 12-16 transmit trigger and context information tothe production engine and, more particularly, the event manager 18 a viaa workflow activation message component. In the illustrated embodiment,this activation component has a single method as defined below:interface IWFActivationMsg : IDispatch  { [id(1), helpstring(“Fire atrigger in Production Engine that will start a workflow using thecontext provided.”)] HRESULT FireTrigger([in] BSTR TriggerName, [in]IDispatch *Context, [out] BSTR *StatusMsg, [out, retval] VARIANT_BOOL*Status);  };

[0159] Database Servers

[0160] In the illustrated embodiment, the configuration database 18 b′contains all data required for the workflow editor, interpreter,configuration client, production engine. Likewise, the productionsupport database 18 b″ contains all data required for the productionengine and run-time clients. Additional tables added to this schemainclude:

[0161] AppserverConfiguration—Contains message queue path names for allsingle occurrence queues such as: the message queue server (node wherethe message queues for the engine were selected to reside), Commonclient queue, expression evaluation queue, event manager administrationqueue, scheduled events queue.

[0162] GenSampleID—table used to provide unique sample ids for datacollection.

[0163] Local Queue Info—Contains the message queue path name for eachnode, node types and computer names for all the nodes in the system

[0164] InWorkStored—table used by runtime clients to persist collectionplan updates (a user can return to their data collection at a latertime).

[0165] Monitors—a list of the monitoring applications installed on thenode type.

[0166] Scheduled Event Module (ScheduledEventsXP)

[0167] In the illustrated embodiment, this is an extended storedprocedure dll containing calls to the Microsoft Message Queue api toplace a message onto the private em_schedule_q message queue. The dllaccepts a trigger name from a stored procedure. The trigger name isplaced in the label of the message.

[0168] Interaction with Other Components

[0169] Event Manager 18 a: The event manager service reads triggerinformation from the production support database 18 b″. Triggers havethe option to be scheduled. When a trigger is scheduled for a particulartime or time interval, event manager uses the SQL demonstrationapplication to create jobs in SQL Server. Each job is created to callthe extended stored procedure with the appropriate trigger name. Eventmanager uses SQL Server's scheduler event mechanism to fire thesetrigger events.

[0170] An Event manager thread constantly monitors the em_schedule_q fortrigger messages from the database server.

[0171] Application Server Detail

[0172] Security Manager Service

[0173] In the illustrated embodiment, the Security Manager is a WindowsDCOM server service used for security checks of Production Engineclients. The users and their access rights are defined in theConfiguration Client database 18 b.

[0174] There are two different interfaces for the Security Manager. TheISecurityConfig interface is for accessing configuration data and theISecurityRuntime interface is for accessing runtime or production data.The Logon method is used to validate and provide access to the user inthe respective mode (config or runtime or both). A zero result from thelogon method means that there was an error, otherwise a handle isreturned that is used to grant/deny access. The RequestAccess method iscalled with the returned handle and the requested access (ConfigRead=1,ConfigReadWrite=2, ManualDataCollection=4, ManualDataSupercede=8,Production Actions=16). The return value of the RequestAccess functionis True for access granted and False for access denied. To log off theuser, the Logoff method is called.

[0175] The clients of the security manager service are the runtimeclients 18 e, 18 f and configuration client (e.g., database 18 b andeditor 18 c).

[0176] Event Manager Structure

[0177] In the illustrated embodiment, the event manager 18 afunctionality is separated into eight different categories: startup,shutdown, abstraction client call-back, scheduled event monitoring,action event monitoring, administration event monitoring, clientresponse monitoring, and expression evaluation monitoring.

[0178] Startup

[0179] During the startup, event manager performs several operations.

[0180] Registry settings are loaded

[0181] Event Objects are created to detect proper shutdown of all eventmanager threads.

[0182] Local queue table is populated with the message queue path namefor each node, node types and computer names for all the nodes in thesystem. Node names and types are stored in the configuration database.

[0183] AppServerConfig table is populated with message queue path namesfor all single occurrence queues such as: the message queue server (nodewhere the message queues for the engine were selected to reside), Commonclient queue, expression evaluation queue, event manager administrationqueue, and scheduled events queue. This information is pulled from theregistry on the application server.

[0184] Message queues are created for transfer of all information.

[0185] Scheduled jobs are created on the database server for eachtrigger requiring initiation by a timed event

[0186] All Triggers, Workflows and Workflow Actions are loaded intoEvent Manager memory into standard template library (STL) maps. Actiondetails are also loaded to enable quick execution of actions when anevent occurs.

[0187] A connection is made to the tag server for ongoing retrieval ofI/O information Four threads are spawned in event manager to monitorfour separate incoming message queues.

[0188] Shutdown

[0189] An event object is created to request the four spawned threads toshutdown. Once shutdown is complete all allocated memory is deallocated.

[0190] Abstraction Client Callback

[0191] A callback method is used to receive data change and alarm eventsfrom InTouch. This call back routine first examines additionalconditions (possibly expressions) to determine whether the triggershould be inhibited. If there are no additional conditions or theconditions return true then a message is placed on the em_internal_q fordetection by the action event monitoring thread.

[0192] Schedule Event Monitoring

[0193] A thread is spawned in event manager to watch the schedule eventqueue. When a message comes in it is immediately sent to theem_internal_q (action event monitoring). This thread was created forlater expansion to allow conditions to be considered before acceptingthe timed event.

[0194] Action Event Monitoring

[0195] A thread is spawned in event manager to respond to incomingtriggers. A trigger arrives either by a data change or alarm event fromInTouch or from a scheduled event. Once the thread detects a message onthe em_internal_q it is examined to determine what workflow should beexecuted. The workflow execution is completed by calling the executemethod on an actionTrigger object. The object resides in a standardtemplate library (STL) name-value pair (name—trigger name, value—actionTrigger object). Currently the actionTrigger.Execute method traverses anSTL vector, containing action object instances, calling each action'sexecute method. Each action object is derived from a base action classallowing this traversal to occur seamlessly. The following actions areprovided: stored procedures, expressions, production actions andcollection plans.

[0196] Stored Procedures

[0197] Stored Procedure actions use ActiveX data objects (ADO) to passparameters to a stored procedure for execution. If a stored procedurecontains output parameters these parameters are written back out to thePDI values. This in turn writes them back to the I/O source using theabstraction client, if the PDI is not a workflow context variable.

[0198] Expressions

[0199] Expression actions use purchased source code for evaluatingcomplex expressions. Parameters are passed to the GEO dll forevaluation. The result of the expression is written back to the PDI.Again this is written to the I/O source using the abstraction client ifthe PDI is not a workflow context variable.

[0200] Production Actions

[0201] Production actions are a series of transactions, here,transactions defined in the InTrack application 12 a. Each actionperforms the operations necessary to setup the InTrack objects in orderto execute the InTrack transactions of (create, start, consume,complete, close, move, and adjust). Parameters from the I/O source orworkflow context variables are used to provide the necessary informationto the transaction. In cases where data is returned from the transactionthe I/O source or workflow context variable is stored.

[0202] Collection Plans

[0203] In the illustrated embodiment, Collection Plan actions representan InTrack data collection action. Additional functionality on top ofInTrack resides in the ability to assign an expression to a collectionplan item. This is accomplished using the GEO application. Theexpression is evaluated (including the specified item parameters asinput). The result is stored as the collection plan item specifying theexpression. Another feature in the collection plans is “storedprocedures in collection plans”. This feature allows the user to insertone or more stored procedure calls into the collection plans. Thesestored procedures are executed using ADO. Each collection plan item,specified for use in the stored procedure, are loaded as parameters intothe ADO object and the appropriate stored procedure is executed. Allcollection plan items are written to InTrack via the automation serveronce all items are evaluated.

[0204] Collection Plans can be automatic, partially automatic, ormanual. Fully automatic collection plans are evaluated by the actionexecution thread and stored to InTrack. Partially automatic or manualcollection plans are transmitted to the runtime client for furtherevaluation. These messages are placed in a message and sent via thecommon runtime client queue. Collection plan actions

[0205] Message Action

[0206] In the illustrated embodiment, all UI message actions aretransmitted to the runtime client via the common runtime client queue.When a message is sent to the queue, the action thread stalls waitingfor the response. Once the client response is received, the parametersof the response are written to the workflow context variables for use byother actions. A pool of threads are created which allow each workflowto execute in it's own thread.

[0207] Administration Event Monitoring

[0208] Administrative events such as responses from the runtime clientare monitored through separate thread. Collection plan messages havetime out conditions which require the operator to respond in a givenamount of time. The types of responses from the runtime client areindications that a

[0209] Client Response Monitoring

[0210] Client responses are monitored within the action eventmonitoring. When a message is sent to the runtime client the thread willstall and wait for a client response on the client response queue.

[0211] Configuration Client Node Detail

[0212] Workflow Editor

[0213] The workflow editor 18 c′ displays and builds workflowsgraphically, thereby permitting user-defined workflows. An exemplaryeditor display, including a sample workflow graphic, is presented inFIG. 21. As shown in the graphical editor pane 2100 of that display, theworkflow 2102 triggers on the All_Manual trigger, as indicated bygraphic 2104. When that occurs, the Machine Ready? user interfacemessage is presented at the operator console (see graphic 2106) and,thereafter, the peCreate production action is exercised (see graphic2108). The graphics 2104-2108 represent components of the illustratedworkflow 2102 and are a subset of the available workflow componentsidentified on the left side of the display, i.e., the workflowcomponents pane 2110.

[0214] Workflow Components Pane 2110 presents a tree view of the variouscomponent categories that are used to build a workflow document. Thecategory “Workflow Instances” contains the item New Workflow, as well asany other previously saved workflow instances. The New Workflow item canbe dragged and dropped onto the editor pane 2100 to create the Start andStop nodes for each workflow document. The category “Triggers” lists allavailable Triggers that have been configured for use in a workflow. Thecategory “Actions” lists available Actions that have been configured foruse in a workflow. In the illustration, The Actions category includesthe following sub-categories: Collection Plans, Expressions, ProductionEvents, and Stored Procedures.

[0215] The Graphical Editor Pane 2100 displays a current workflowdocument that is being edited or blank if it is a new document. In theillustrated embodiment, this can contain any of the following workflownodes: Start node, which is created when a New Workflow is dragged anddropped onto the editor pane. In the illustrated embodiment, onlyTrigger nodes can be dropped on the Start node, though other embodimentsmay vary.

[0216] As evident, then, the workflow can further include a Triggernode, which is created when a Trigger node is dragged and dropped on theStart node. In the illustrated embodiment, only the one Trigger node canbe added to a workflow, though other embodiments may vary. In theillustrated embodiment, if a workflow contains a Trigger node andanother is dropped onto the Start node, the editor prompts the user ifit should replace the existing Trigger node.

[0217] A workflow in the illustrated embodiment can further include anAction node, which is created when an Action node is dragged and droppedon the Trigger or any other Action node.

[0218] Finally, in the illustrated embodiment, a workflow can include aStop node, which is also created when a New Workflow is dragged anddropped onto the editor pane. Like the Start node, in the illustratedembodiment, the Stop node cannot be deleted and, like the Start node,only Trigger nodes can be dropped on this node.

[0219] In order to create (or editor) a workflow, the user dragstriggers onto an empty workflow which, in the first instance, is denotedby “start” and “end” graphics, 2112, 2114, respectively. In theillustrated embodiment, once that trigger is associated to a workflow itcannot be used in another workflow; other embodiments may vary in thisregard. Actions, too, are dragged onto the workflow and appended intothe workflow 2102 graphic. Action ordering is decided by the order inwhich these graphics they follow the start node. This ordering iswritten to the configuration database tables. After interpretation,Event Manager 18 a uses the production support database 18 b″ todetermine actual execution order of the workflow.

[0220] Though a linear workflow is shown in the drawing, as indicated bythe linear arrangement of nodes and the line segments connecting them,the illustrated workflow editor allows for creation and display ofdecisions, transitions, conditional branches (multi-branch—3 or morechoices), parallel workflows and subworkflows. Such workflows is can berepresented in flowchart-like or graphical programming-like iconography.Thus, for example, decisions can be represented diamond- (or other-)shaped nodes that connect to different respective action nodes.Conditional branches can be likewise represented. Parallel work flowscan be represented, for example, by two or more linear segments (each,for example, including a respective set of one or more action nodes)disposed side-by-side or otherwise. Preferably, modeling of decisions islimited to a controlled mechanism to form workflows. The editor alsosupports conditional branches, where the expressions are more complexand result in multiple results such as you would see in a programmingcase statement.

[0221] In the illustrated embodiment, underlying the workflow workspaceis a hidden grid. This forces alignment of actions into grid locationsto allow for a uniformed look to the workflow. The user is allowed todrop an action next to a decision to allow for connection from the mainbranch of the workflow. The user can connect decision actions to otheractions and can supply the expected results of the decision action. Theresults for each branch of the decision determine the direction of theflow. The workflow editor stores the ordering of the action informationalong with a series of choices of next actions. In the case of actions,which are not decisions, there is only one possible next action. In thecase of decision actions, there are two choices based on a result.Expression functionality executes these decisions.

[0222] Drawing and manipulation of graphical objects in the illustratedembodiment is implemented using the commercially available GO++ add-onto the Microsoft Foundation Classes (MFC), though other graphical objectmanipulation tools, whether or not based on MFC, may be used in additionor instead. The editor of the illustrated embodiment also uses aCOM-based data access object mechanism referred to as OLEDB calls toread configuration data from the configuration database 18 b′, thoughother methods of database connectivity or access can be used. Followingcompletion of a graphical model, the user can save that information backto the configuration database. Once the interpreter 18 d is run the datais transferred to the production support database 18 b″, where it isread at event manager restart to recognize the new workflows.

[0223] With further attention to details of implementation of theillustrated embodiment, the MFC Document/View Architecture is used forboth the workflow components pane and the graphical editor views, asdiscussed below.

[0224] Workflow Components Pane

[0225] CTreeView that is used to hold information about each node theWorkflow Editor supports. Each tree item has a class associated with it(Workflow, Trigger, and Action). For each of these classes a collection(C++ vector) has been defined to contain them. A WFComponents class isbeen defined that includes each one of these collections (Workflow,Trigger, and Action) as member variables.

[0226] Referring to FIG. 22, only one WFComponents object isinstantiated when the Workflow Editor runs. The Workflow, Trigger, andAction classes are used to instantiate objects that have their datamembers populated by loading from the tables defined in the MS SQLServer database.

[0227] The WFComponents data members include: Workflow, which uses acombination of tables (Workflow, WorkflowActivity, Activity,ActivityAction, Actions, TriggerActions, and TriggerObject); Trigger,which uses the TriggerObject table; and Action, which uses the Actiontable. The WFComponents class also includes methods that support thefollowing (vectors refer to Workflow, Trigger, and Action collections):

[0228] Clear( )—clears all vectors

[0229] Load( )—loads all vectors with the appropriate data from the MSSQL Server database.

[0230] Reload( )—issues a Clear( ) and Load( ), described above.

[0231] SaveWorkflows( )—support for saving vector data to the MS SQLServer database.

[0232] Graphical Editor Pane

[0233] CWFEditorView derived from CGoGridView is used to support all ofthe graphical operations the Workflow Editor uses. The nodes that arecurrently supported are: WFNode, which is derived from CGoArea (GO++).Used as the base class for all Workflow Editor nodes; WFStartNode whichis derived from WFNode; WFTriggerNode which is derived from WFNode;WFActionnode which is derived from WFNode; and WFStopNode which isderived from WFNode

[0234] CWFEditorDoc is derived from CGoDocument and is used to supportall necessary document functionality that is used for the WorkflowEditor. Workflows are stored in a MS SQL Server v7.0 database. FIG. 22shows the tables used in the database of the illustrated embodiment andthe relationship between them.

[0235] Workflow Context

[0236] Workflow Context permits a set of associated events to work on aset of data that is particular to them, much like a program uses a localvariable set inside a function. Using this metaphor, a workflow is likea function and the set of actions within that workflow is like theinstructions within the function. Actions are permitted to operate uponthe Workflow Context much like the instructions of the function operateupon the function's local variable set.

[0237] In the illustrated embodiment, every workflow maintains aWorkflow Context. This context is an association of variable name withvariable type/value. The Workflow Context can be initialized uponinstantiation of the workflow through a Workflow Activation Message. TheWorkflow Activation Message contains a Workflow Context which is aproper subset of the instance of the workflow. Upon instantiation of theworkflow, the Workflow Context from the Workflow Activation Message isassumed by the workflow's Workflow Context. As the workflow executes,actions within the workflow operate upon the Workflow Context by gettingand/or setting the values associated with the name of the entry in theWorkflow Context with which they are interested. Actions are able toincrease the workflow's context by setting values that are not currentlypart of the Workflow Context. These entries are then available to theaction from that point on as well as being accessible to subsequentactions in the workflow.

[0238] The entries within a Workflow Context are manipulated, in theillustrated embodiment, by the same subsystem that manipulates tagsassociated with physical I/O. This subsystem determines the type of itemupon which information is requested. If it is a tag, the subsysteminterfaces with the I/O subsystem. If it is part of a Workflow Context,the subsystem either gets or sets the value within the Workflow Context,as requested.

[0239] Workflow Context Variables

[0240] In the illustrated embodiment, workflow variables are implementedas parameters to an event-generated trigger. The trigger is signaled viaa message (with its label set to the trigger name) on Event Manager'sinternal queue. See FIG. 25, step 2502. This is how event-generatedtriggers also occur in the illustrated embodiment. The difference with aworkflow trigger is that the workflow context variables are specified inthe message body as an XML string representing the context in aname/value-pair collection (the workflow context).

[0241] In response to the message, the Event Manager searches for anaction-trigger object (loaded by EM on startup) by the name specified inthe message label. See step 2504. Once found, EM calls thisaction-trigger's execute method. See step 2506. The workflow context XMLstring is passed to this method. The action-trigger's Execute methodcreates a C++ standard template library (STL) map filled with theassociations from the XML string passed as an argument. See step 2508.This map now has the name/value pairs collection, or workflow context,in the form of a string for the name and a CComVariant as the value foreach pair.

[0242] The action-trigger, next, loops over all the actions that werebound to it, passing the workflow context map to each one. See step2510. Each action implements an Execute method which takes a referenceto this workflow context map. As described in the section that follow,all workflow variables of the illustrated embodiment are implemented inthe configuration system as PDIs. These special PDIs have a prefix ofwf_. As the actions execute, the CPDIRead and CPDIWrite objects arecalled to get or set the values of PDIs. These objects are instantiatedwithin the action they are needed and passed a pointer to the workflowcontext map, which was also passed into the action. When the CPDIRead orCPDIWrite objects are asked to provide the value of a workflow variable,instead of going to the tag system, the workflow context map is accessedor modified.

[0243] As the actions are executed, the workflow context map is accessedand modified. See step 2512. The modifications are carried from actionto action. In this way, subsequent actions have access to values in theworkflow context map set by some previous action. Actions are configuredto access either workflow context variables or PDIs. To the action,there is no difference: the CPDIRead and CPDIWrite objects handle thedetails. Expression evaluation actions are configured to set the valueof a PDI based on the value(s) of workflow context variable(s). Theseactions may be configured with a mix of workflow variables andnon-workflow PDIs, on the right side of the expression and either typeon the left.

[0244] Workflow Variables

[0245] In the illustrated embodiment, workflow variables are implementedas parameters of a trigger and can be accessed via the WorkflowVariables tab of the corresponding trigger object in the configurationeditor 18 c; see, for example, FIG. 26. Code for implementing this canbe based on that used for action manipulation, e.g., the templatefunctionality (modify, delete, insert, append), the transactionfunctionality (save, restore, modify) and the variable manipulationfunctionality (variable up/down). One difference is the addition of aseparate workflow variable cache. Variables are created as a PDI,however they are not stored in the respective PDI tables. Rather,referring to FIG. 27, they are written to a PDI object table 2702. Anadditional table—workflow context table 2704—serves as a referencelinking triggers, in the trigger object table 2706, with specificassociated variables in table 2702, as shown in the drawing.

[0246] Variables are initially written to the database and stored in atemporary state until either a save is called or they are deleted (orthe application is closed). This allows for restoration of a templatethat was changed but not saved with the trigger. The following flags areused for this function: Save Data Flag Condition 0 Added but not savedwith trigger 1 Added and saved with trigger 2 Delete but not saved

[0247] In the illustrated embodiment, all workflow variables are createdwith a prefix of “wf_” and appear in all drop-down PDI selectors uponcreation. After a workflow variable is created and associated with atrigger, it can be used by a different trigger but it's data type cannotbe changed due to database referential integrity.

[0248] Association of WorkFlows and Order/Lot IDs

[0249]FIG. 23 illustrates how orders and lot IDs from ERP or otherexternal systems are associated with workflows created in the WorkflowEditor. One such external system is illustrated here as element 2310;further such systems (not shown) can be provided, as well.

[0250] A work scheduler 2320 associates orders numbers from the externalsystem 2310 with lot IDs maintained by the aforementioned InTrackapplication. In a particular example shown in the drawing, Order 1239from the external system 2310 is shown associated with Lot ID “PurpleWidget”, Workflow “Widget Workflow”, Machine Group “Group 1”, Quantity“100” and Lines/Train “Line 1”. Further associations, not shown in theillustration, are provided for Orders 1234-1237 and 1240-1242. The workscheduler 2320 can be an editor, e.g., with a graphical interface of thetype shown in the drawing, or otherwise. It can also be a batch system,a script, a macro, a program or otherwise that generates the indicatedassociations.

[0251] Regardless, a function is provided for scheduling the indicatedorder, here, Order 1239, through selection of the illustrated “Schedulethis Work” button. Orders can, of course, be scheduled in other ways,depending on the type of work scheduler 2320 and the user interface, ifany, provided thereby. When that function is exercised, the specificassociation is stored in a table (not shown) in the production database18 b″.

[0252] Within at least selected real-time clients 18 e, 18 f, an ActiveXcontrol reads “work” information directly from the aforementioned tablefor display to the operator via the corresponding workstation. A displayof the type generated by that control is indicated by element 2330 inthe drawing. Here, that display shows that, as of 10:58 AM, on Mar. 5,2002, work available for the applicable real-time clients workstationincludes “Use Lot 992 to Create 100 Widgets.” Other work available forthat workstation includes use of Lot 123 to create 9 red widgets,processing of Bin 5 of blue widgets, and use of Lot 342 to create 25widgets. In alternate embodiments, interface mechanisms other than (orin addition to) ActiveX controls are used to display information fromthe aforementioned table to the operator. In yet still otherembodiments, ActiveX controls or other interface mechanisms are used toconvey information from the aforementioned table directly to controlequipment (, e.g., other than operator workstations).

[0253] Regardless, a function is provided for generating a trigger,e.g., for indicating the start of the scheduled work. Here, thatfunction is exercised by an “Start this Work” button provided on theActiveX control. In other embodiments, the function is exercisedotherwise by the user or control equipment. When the trigger isgenerated, the ActiveX control (or other interface) directly inserts anew trigger record into the trigger queue (see “Internal Trigger Q”,FIG. 7); and other embodiments, the triggering event can be signaledotherwise (e.g., via messaging of the Event Monitoring “front and” ofEvent Manager 18 a). The trigger contains not only a standard triggerID, but also a collection of context information (e.g., lot ID, workflowID, machine Group, quantity, line/train, and so forth—as indicated inthe drawing) corresponding to the data in the aforementioned table ofthe production database 18 b″.

[0254] In the illustrated embodiment, the workflow schedule or 2320 isconfigured on a custom basis per project. The remaining functionalityshown in the drawing is, across all projects and workflowimplementations.

[0255] Runtime Client Node Detail

[0256] ActiveX Controls

[0257] The runtime client consists of several activeX controls addedinto application runtimes 12 a, 14 a, 16. The runtime client 18 e, 18 fincludes activeX controls, as described below, which facilitate supportcommunications coupling with the production engine and, moreparticularly, for example event manager 18 a and other components of thesystem 10. Here, as elsewhere in the illustrated embodiment, thoughimplemented in activeX, it will be appreciated that other programmingconstructs, containers and/or components (whether or not based onMicrosoft™ COM (component object model) technology or equivalentsthereof, such as OLE, COM+, DCOM, JAVA, OpenDOC, Netscape LiveConnect)can be used in addition or instead.

[0258] UI Message Control

[0259]FIG. 3 illustrates an activeX control of the type used in aruntime client, e.g., 18 e, to provide communications coupling betweenthat client and the production engine 18 a. As shown in the drawing, arefresh method populates a user prompt list provided in the control 300with all Message Queue messages labeled as User Prompts. Double clickingan item in that list causes the a function IUIMessageDisplay totransform the message body to the UIMessage Display control. Afterediting, a successfully submitted User Prompt is sent to the responsequeue. The file system of the digital data processor on which thecontrol (and, more generally, the runtime client 18 e) is executedmaintains received queue messages until the message has beensuccessfully submitted.

[0260] AlarmClient Control

[0261] This control depends on data from the production support database18 b″ (also referred to as the “ProdSupport” database). It receivesalarm arrived events from alarm sub-system. An alarm consumer dllinterfaces to an Alarm Monitoring DCOM server. The Alarm monitoring DCOMserver polls the alarm subsystem of an application 12-16 (e.g., inTouchapplication 12 a) for alarms.

[0262] PDISelector Control

[0263] This control combines data from production support database 18b″, the application databases (e.g., InSQL database 14 b) and a runtimedatabase.

[0264] ActiveClient Control

[0265] The control combines data from production support database 18 b″and the runtime database. It depends on the production engine formessage queue server information and PDI information from productionsupport database 18 b″.

[0266] QueueArrived Control

[0267] This control polls message queue for incoming messages. It usesproduct support database to determine queue information.

[0268] ParetoChart Control

[0269] This control combines data from the production support database18 b″, the runtime database and one or more application databases (e.g.,InSQL database 14 b). The chart is able to provide information based onthe following inputs: PDI information, configured collection planinformation.

[0270] Trend Control

[0271] This control combines data from the production support database18 b″, the runtime database and one or more application databases (e.g.,InSQL database 14 b). The control has the ability to trend on thefollowing: configured PDIs, configured collection plan information.

[0272] SecurityDialog Control

[0273] This control interfaces to security manager service ofapplication server to validate configured users.

[0274] Data Structures

[0275] Production engine 18 and, particularly, event manager 18 a, areimplemented utilizing objects implemented from classes of a structure ofthe type shown in FIG. 4. It will be appreciated that other classstructures and data types may be used in addition or instead.

[0276] Populating Data Collection—User Action List

[0277]FIG. 5 depicts steps utilized in a system according to theinvention to populate a data collection. In step 1, a list is requestedof user-initiatable items from production support database 18 b″. Instep 2, a list of pending items is requested from MSMQ. In step 3, thelist of in-work items are requested from the node's localdatabase/queue. Records in the MSMQ and in the local storage areidentical. In the illustrated embodiment, they have the data collectiontemplate name and the InTrack record id, e.g., “Data Collection TemplateName ‘Bob’”|“InTrack Record ID# 1234” as shown in the drawing.

[0278] Action Message Life Cycle

[0279]FIG. 6 depicts an action message life cycle in a system accordingto the invention. In step 1, the Event Manager creates partial record inthe InTrack (or other application) database 12 b′ (via itsSaveMachineSample( ) function, or another such facility in anotherapplication). In step 2, it creates a Queue message and places it in theoutbound MSMQ Queue. In step 3, a Client decides to pull action recordfrom queue and work on it. The control performs a ‘get message’ on theMSMQ, effectively removing the message from the queue. In step 4, theclient writes this action record (same information) down to a localpersistence storage mechanism (database, queue, etc.). In step 5, theclient reads partial record from the database 12 b and populates a datacollection screen. The client writes another partial record out ifoperator sets this data collection aside to work on later. In step 6,the client has completed all work on the action and has elected to“close” the action. The control writes the final record to InTrack andremove the action from the local storage.

[0280] Production and Configuration Databases

[0281] In the illustrated embodiment, the tables below are common to theconfiguration and production databases 18 b′ and 18 b″.

[0282] Action

[0283] The Action table identifies Actions in the illustrated system.Actions may be one of several types indicated by the ActionType field.Field Name Field Format Field Description ActionIndex Int NOT NULL(Primary Unique Index Key) ActionName Varchar(30) NOT NULL Name ofAction (unique) Description Int NULL Points to a multi-lingual textdescription of the Action, using StringConversion.StringID ActionTypeTinyint NULL Type of Action: 1 = Collection Plan 2 = Production Event 3= Process Message (Msg Port) 4 = Expression 5 = E-mail 6 = SQL StatementSecurityType Int NULL Describes the type of security check done foroperators executing the action (Used for Collection PLans and ProductionEvents mainly) 1 = Use Login UserID 2 = Always prompt user forUserID/Password check (every transaction) WorkstationGroupIndex Int NULL(Foreign key) FK to WorkstationGroup This group identifies whichworkstations may perform the Action.

[0284] ActionEmail

[0285] This table is describes the E-Mail type of Action. Each E-Mailaction has a record in this table. In the illustrated embodiment, it ismapped 1:1 with Action Where ActionType=5 Field Name Field Format FieldDescription ActionIndex Int NOT NULL (PK) FK to Action tableIntendedReceiver Varchar(40) NULL e-mail name of recipientMessageContent Int NULL Pointer to string as StringConversion.StringID

[0286] ActionExpression

[0287] This table is specifically for Expression type Actions. FieldName Field Format Field Description ActionIndex Int NOT NULL (PK) FK toAction Table ActionSegment Int NOT NULL (PK) Numeric Sequence number forjoining multiple Expressions together PDIObjectIndex Int NOT NULL (FK)FK to PDIObject table. Identifies the PDI that is the target for theresult of the expression. ExpressionType Int NOT NULL Type ofExpression: 1 = PDI Expression (Expression is composed of PDIs andmathematical operators) 2 = SQL Expression (Expression is a SQLStatement) Expression Varchar(255) NULL The expression textConnectString Varchar(120) NULL For SQL Expression Type (2), this is theconnection string to the database for the SQL statement.

[0288] ActionSQL

[0289] This table identifies a SQL expression to be executed forActionType=6. This differs from the Expression type of Action in thatthe result of the SQL Statement is not used to populate a PDI value.Field Name Field Format Field Description ActionIndex Int NOT NULL (PK)FK to Action SQLStatement Varchar(120) NULL SQL Statement textConnectString Varchar(120) NULL String used for Database connection

[0290] AlarmGroup

[0291] This table lists all the Alarm Groups for the illustrated system.This is primarily used by the InTouch Tag Server to group alarms intohierarchical sets. These sets can be used by the clients to filter outalarms that are not of concern to the operator. Field Name Field FormatField Description AlarmGroupIndex Int NOT NULL (PK) Unique IndexAlarmEnablePDI Int NULL (FK) Foreign key to PDIObject. Identifies aDiscrete PDI which acts as an enable mechanism for alarming. If NULL,the alarm group is always enabled. AlarmGroupName Varchar(30) NOT NULLUnique name for Alarm Group Description Int NULL Pointer to StringID inStringConversion table

[0292] AlarmItem

[0293] This table identifies single alarms in an AlarmSet. Each recordin this table represents a different type of alarm for the alarm set.Field Name Field Format Field Description AlarmSetIndex Int NOT NULL(PK) FK to AlarmSet AlarmType Varchar(8) NOT NULL Type of Alarm usingInTouch (PK) naming convention: ‘HI’, ‘HIHI’, ‘LO’, ‘LOLO’, ‘ROC’,‘MajorDev’, ‘MinorDev’, ‘On’, ‘Off’ Note: ‘On’ and ‘Off’ are forDiscrete PDIs only. All others are for Numeric PDIs only AlarmValueFloat NOT NULL Alarm Limit Value AlarmPriority Int NOT NULL Priority1-999 (1 is most important)

[0294] AlarmSet Field Name Field Format Field Description AlarmSetIndexInt NOT NULL Unique Index (PK) EstablishingStandard Int NULL FK toPDIObject table Identifies the Standard or Non-Standard PDI whichcreated the AlarmSet DevTarget Float NULL The Deviation Target valueused for MajorDev and MinorDev alarm types (see AlarmItem) ROCUnitsVarchar(4) NULL Units for the Rate-Of-Change (ROC) alarm type (seeAlarm- Item)

[0295] ATEvent

[0296] In the illustrated embodiment, this table is 1:1 with theTriggerObject table for ATEvent type triggers Field Name Field FormatField Description TriggerIndex Int NOT NULL FK to TriggerObject (PK)PDIObjectIndex Int NULL FK to PDIObject table. Identifies the PDI thatis being monitored for comparison. ComparisonType Int NOT NULL Type ofComparison done on the PDI: 1. == x 2. < x 3. > x 4. <= x 5. >= x 6. <>x 7. Any Change 8. Change By x 9. AlarmState changed to xComparisonValue Varchar(20) NULL Formatted string for ‘x’ in the aboveexamples. X is a floating point number for all cases but type 9.

[0297] ATSchedule

[0298] In the illustrated embodiment, this table is 1:1 withTriggerObject for Schedule type Triggers. Field Name Field Format FieldDescription TriggerIndex Int NOT NULL (PK) FK to TriggerObject StartTimeDatetime NULL Starting time MinuteInterval Tinyint NULL Period betweentrigger events in minutes HourInterval Tinyint NULL Period betweentrigger events in hours ShiftIndex Int NULL FK to Shift table.Identifies the shift for the event. Days Smallint NULL Period betweentrigger event in days. WeeklyTriggerDay Tinyint NULL Identifies the dayof the week for weekly trigger events: 1. Sunday 2. Monday 3. Tuesday 4.Wednesday 5. Thursday 6. Friday 7. Saturday Month Selection Int NULLSelects which months the trigger will occur (bitwise AND ...)   1 =January   2 = February   4 = March   8 = April  16 = May  32 = June  64= July  128 = August  256 = September  512 = October 1024 = November2048 = December

[0299] ATSecConstraint

[0300] This table identifies secondary constraints on triggers using aPDI expression. Field Name Field Format Field Description TriggerIndexInt NOT NULL (PK) FK to TriggerObject Expression Varchar(50) NULL Textexpression composed of PDIs and numerical operators

[0301] ATSecConstraintSQL

[0302] This table identifies secondary constraints on triggers that aremade with a SQL statement. Field Name Field Format Field DescriptionTriggerIndex Int NOT NULL (PK) FK to TriggerObject SQLStatementVarchar(120) NULL SQL Statement text ConnectString Varchar(120) NULLConnect string text for database connection

[0303] CollectionItem

[0304] This table identifies individual items to be collected as part ofa Collection Template. Each item identifies a “slot” in the collectionplan. Multiple collection plans may share the same Collection Templateand therefore the same set of CollectionItems. Field Name Field FormatField Description CollectionItemIndex Int NOT NULL (PK) Unique IndexCollectionTemplateIndex Int NOT NULL FK to CollectionTemplate ItemNumberIn NOT NULL Unique within the template, this field orders the itemssequentially HeaderItem Bit NOT NULL TRUE when the item is in the Headersection of the plan. CollectionItemName Varchar(30) NOT NULL Uniquewithin the template this names the columns used in the collection plan(used by InTrack to name the DataSet Items for the DS Template) PDITypeTinyint NOT NULL Type of PDI (see PDIObject)

[0305] CollectionPDI

[0306] This table lists the specific PDIs that are mapped toCollectionItems for each Collection Plan. Field Name Field Format FieldDescription CollectionItemIndex Int NOT NULL (PK) FK to CollectionItemActionIndex Int NOT NULL (PK) FK to CollectionPlan (Action)PDIObjectIndex Int NULL FK to PDIObject identifies the PDI to map to thecollection item for this collection plan Automatic Bit NOT NULL TRUEwhen the PDI value is collected automatically by EventMgr. False meansthe value is manually collected by operator. Required Bit NOT NULL TRUEwhen the operator is required to enter a value for this item. Falsemeans data entry is optional. Description Int NULL Pointer to StringIDin String- Conversion table. Optionally describes the PDI/CollectionItem relationship. Expression Varchar(120) Text expression tobe used by Run-Time client for automatically filling in the item withthe result of an expression based on values of other entered items.DefaultValue Varchar(30) NULL Default value for the CollectionPDI whenfilled in by EventMgr, o when presented to operator for manualcollection. This is a formatted float for numeric PDIs.

[0307] CollectionPlan

[0308] In the illustrated embodiment, this table is 1:1 with Actionwhere ActionType=1 Field Name Field Format Field Description ActionIndexInt NOT FK to Action NULL (PK) CollectionTemplateIndex Int NULL FK toCollectionTemplate PlanType Int NULL Type of Collection Plan: 1 = Manual2 = Manual Standard 3 = Automatic 4 = Automatic Standard 5 = Combo 6 =Combo Standard Lifecycle Int NULL Expiration time in minutes for theCollection plan to be fulfilled. LocationIndex Int NULL FK to Locationtable. Optionally associates the Collection plan to a location.MachineIndex Int NULL FK to Machine Table. Optionally associates theCollection plan to a machine.

[0309] CollectionTemplate Field Name Field Format Field DescriptionCollectionTemplateIndex Int NOT NULL (PK) Unique IndexEstablishingStandard Identifies the Collection A Collection Template isplan (standard or non- shared by all regular Cplans standard) whichcreated linked to a standard. This the CollectionTemplate fieldidentifies which Cplan is the standard that created it. It alsoidentifies the regular Cplan when it is independently configured (doesnot use a standard)

[0310] ControlItem

[0311] This table identifies target and limit sets by PDI, ProductGroup, and Effective date. Field Name Field Format Field DescriptionControlSetIndex Int NOT NULL (PK) FK to ControlSet EffectivityDateDatetime NOT NULL (PK) Date the target and limit set is to take effect.MaterialGroupIndex Int NOT NULL (PK) FK to MaterialGroup. Identifies theMaterial (Product) Group for the target/limit set. Description Int NULLPointer to StringID in the StringConversion table. Target Float NOT NULLThe target value for SPC analysis CL Float NOT NULL The Control Limitmean for SPC analysis USL Float NOT NULL Upper Specification Limit UCLFloat NOT NULL Upper Control Limit LCL Float NOT NULL Lower ControlLimit LSL Float NOT NULL Lower Specification Limit Rmean Float NULLExpected mean value for Range RUCL Float NULL Upper Control Limit onRange RLCL Float NULL Lower Control Limit on Range

[0312] ControlSet

[0313] This table groups the target and limit sets given by theControlItem table into sets for standardization. Every PDI for SPCanalysis has a ControlSet. This can be standardized so that several PDImay share the same control set. Field Name Field Format FieldDescription ControlSetIndex Int NOT NULL (PK) Unique IndexEstablishingStandard Int NULL Identifies the PDI (PDIObjectIndex) whichcreated the Control Set.

[0314] DataRetention

[0315] This table defines the global data retention parameters for theillustrated system. Field Name Field Format Field DescriptionDataRetentionIndex Int NOT NULL Unique Index HistoryDaysOnline Int NOTNULL Number of days to keep History records online HistoryDaysArchivedInt NOT NULL Number of Days to keep history records archivedSPCDaysOnline Int NOT NULL Number of days to keep SPC data onlineSPCDaysArchived Int NOT NULL Number of Days to keep SPC records archivedOnlineLocation Varchar(50) NULL ??? OnlineStorage Varchar(50) NULL ???

[0316] EventType

[0317] This table enumerates the event types possible with ProductionEvents. The table is pre-populated with the types supported by theillustrated system. In the illustrated embodiment, the supported EventTypes are: EventTypeIndex EventTypeName 1 Sublot Create 2 Sublot Start 3Sublot Consume 4 Sublot Complete 5 Sublot Close 6 Sublot Move 7 SublotAdjust Field Name Field Format Field Description EventTypeIndex Int NOTNULL (PK) Unique Index EventTypeName Varchar(30) Name of Event Type

[0318] IOAccess Field Name Field Format Field Description IOAccessIndexInt NOT NULL (PK) Unique Index IOAccessName Varchar(30) NOT NULL UniqueName for IOAccess Description Int NULL FK to StringID in String-Conversion table NodeName Varchar(50) NULL Name of Node for serverTopicName Varchar(50) NULL Name of topic for server ServerNameVarchar(50) NULL Name of server application Protocol Tinyint NOT NULLProtocol index: 1 = DDE 2 = SuiteLink Advise Tinyint NOT NULL Identifieswhich items to advise: 1 = All 2 = Active Only

[0319] PDIGroup

[0320] This table defines groups of PDIs. PDIs can be grouped forreports, displays, etc. Groups can be public or private. Field NameField Format Field Description PDIGroupIndex Int NOT NULL (PK) UniqueIndex PDIGroupName Varchar(30) Unique Name for Group NOT NULLDescription Int NOT NULL FK to StringID in StringConversion table. Textdescription of PDI Group PDIGroupType Int NOT NULL The Type of PDIGroup: 1 = Report Group 2 = Display Group SecurityIndex Int NULL FK toSecurityID table. Identifies the owner of a private PDI Group. A NULLindicates that the group is public.

[0321] PDIGroupMembers Field Name Field Format Field DescriptionPDIGroupIndex Int NOT NULL (PK) FK to PDIGroup Identifies the PDI Group.PDIObjectIndex Int NOT NULL (PK) FK to PDIObject Identifies the PDI.

[0322] PDINumber

[0323] Field Name Field Format Field Description

[0324] PDIObject

[0325] This table identifies PDIs of all types. It contains informationcommon to all PDI types. Field Name Field Format Field DescriptionPDIObjectIndex Int NOT NULL (PK) Unique Index PDIName Varchar(30) NOTNULL Unique Name Description Int NULL FK to StringID in StringConversiontable PDIGroup Varchar(50) NULL Not Used PDIType Tinyint NOT NULL Typeof PDI:  1 = Discrete  2 = Discrete Standard  3 = List  4 = ListStandard  5 = Number  6 = Number Standard  7 = Text  8 = Text Standard 9 = DateTime 10 = DateTime Std. 11 = Message Port Item MachineIndex IntNULL FK to Machine. Optionally associates the PDI to a MachineLocationIndex Int NULL FK to Location. Optionally associates the PDI toa Location ActualValueTag Varchar(50) TagName to be created in InTouch.Current implementation is to use the PDIName for this field. Noindependent configuration. IOAddressIndex Int NULL FK to IOAddress.Identifies the IOAddress and Access used for PDIs linked to PLCaddresses or other foreign applications. NULL indicates a “Memory” PDIwhose value is not linked to a foreign application but is heldinternally in memory. (InTouch Memory Tag)

[0326] ProductionEvent Field Name Field Format Field DescriptionActionIndex Int NOT NULL (PK) 1:1 with Action table EventTypeIndex IntNOT NULL FK to EventType (See EventType) Lifecycle Int NOT NULL Numberof minutes to keep Production Event active waiting for operator input.LineIndex Int NULL FK to Line table. Identifies the Line

[0327] ProductionItem

[0328] This table enumerates the parameters for each ProductionEventType. This table is pre-populated with the set of parameters foreach EventType in the EventType table (see Event-Type). Field Name FieldFormat Field Description ProductionItemIndex Int NOT NULL (PK) UniqueIndex EventTypeIndex Int NOT NULL (FK) FK to EventType Identifies theEventType ItemNumber Int NOT NULL Orders the parameters for eachEventType ItemName Varchar(30) Name of the parameter NOT NULL PDITypeInt NOT NULL Data Type for the parameter (See PDIObject)

[0329] ProductionPDI

[0330] This table lists the parameters for each real ProductionEvent andthe PDI or Expression assignment. In the illustrated embodiment,expressions are a constant value. In alternate embodiments, arithmeticand string expressions are supported. The Expression and PDIObjectfields are mutually exclusive. One and only one of these two fields mustbe NULL. Field Name Field Format Field Description ProductionItemIndexInt NOT NULL (PK) FK to ProductionItem Identifies the parameter name anddatatype. ActionIndex Int NOT NULL (PK) FK to ProductionEvent Identifiesthe specific ProductionEvent the Parameter/PDI mapping is for ExpressionVarchar(120) NULL Text Expression Must be a constant valuePDIObjectIndex Int NULL FK to PDIObject table. Identifies the PDI mappedto the parameter. Automatic Bit NOT NULL When True, this value isevaluated by the control system and entered When False, the value mustbe supplied by an operator.

[0331] SPCAlarm

[0332] This table identifies the SPC Alarms which have been configuredfor each PDI (DataSet) Field Name Field Format Field DescriptionSPCRuleIndex Int NOT NULL FK to SPCRule (PK) SPCAlarmType Int NOT NULLType of SPC Alarm: (PK)  1 = Samp Outside Spec Limits  2 = Samp OutsideControl Limits  3 = 2 of last 3 outside 2 SD (Same Side)  4 = 4 of last5 outside 1 SD (same side)  5 = x of last y outside z SD  6 = x of lasty outside z SD (same side)  7 = x consecutive inside 1 SD  8 = xconsecutive outside 1 SD  9 = x consecutive increasing or decreasing 10= x consecutive alternating up/down 11 = x consecutive on one side ofcenterline NumberOfSamples Int NULL Number of Samples involved in alarmdetermination. (x in above type list) LastConsecSample Int NULL Numberof last consecutive samples involved in alarm determination. (y in theabove type list) NumberOfStdDevs Float NULL Number of StandardDeviations (SD) involved in alarm determination. (z in the above typelist) AlarmPriority Int NOT NULL Priority of Alarm 1-999 1 is mostimportant. CauseRequired Int NULL Indication that the operator isrequired to enter a cause code when this alarm occurs. 1 = CauseRequired 0 or NULL = Not required

[0333] SPCRule Field Name Field Format Field Description SPCRuleIndexInt NOT NULL (PK) Unique Index EstablishingStandard Int NULL Identifiesthe Number PDI (Standard or Regular) which created the SPCRule record byPDIObjectIndex AnalysisType Int NOT NULL SPC Analysis Type:  0 = Xindividual  1 = X Bar, R  2 = X Bar, s  3 = Moving X, Moving R  4 = (NOTUSED)  5 = C  6 = P  7 = NP  8 = U  9 = EWMA 10 = CuSum MovingXSamplesInt NULL Number of Moving X Samples, required for AnalysisType = 4 only.MovingRSamples Int NULL Number of Moving R Samples, required forAnalysisType = 4 only. AutoCalcSamples Int NULL Sets the number ofsamples collected between automatically recalculating new controllimits. NULL indicates no automatic recalculation is to be performed.SamplesPerLimitCalc Int NULL The number of most recent samples to usefor the automatic limit recalculation. MeasurementsPerSample Int NOTNULL Number of Measurements Per Sample.

[0334] Event Manager

[0335]FIG. 7 depicts event processing in an event manager 18 a accordingto one practice of the invention. The illustration depicts embodimentSor instances where there is no persistence in data flows.

[0336] In the illustrated embodiment, a scheduled event message,notification or other indicator (collectively, “scheduled event”) S1 isgenerated by the SQL server based on a search of the production database18 b″ for scheduled events or other triggering conditions. Othermechanisms may be used to identify schedule events, e.g., non-SQLdatabase searches, timers, scheduled events lists, and so forth.Regardless, the event S1 is queued or otherwise stored for processing ona FIFO or other basis. And, indeed, in some embodiments, selected (orall) events made available for immediate communication to the eventmanager 18 a.

[0337] Like the scheduled event S1, a device input i1—that is, inputsfrom process or other control equipment to which the applications 12-16are coupled—are generated by the respective applications, here, tagserver associated with the inTouch™ application 12 a. The device inputi1 may be made available for immediate communication to the eventmanager 18 a or, for example, as here, transmitted from the tag server(or other server, database management system or other store, managerand/or monitor of tags or other device input/output events) viaillustrated abstraction client that reformats, maps and/or otherwiseinsures proper formatting, consistency and/or uniqueness among deviceinputs i1 received, potentially, from a variety of applications 12-16.

[0338] Following queuing, if any, event monitoring functionality in theevent manager polls, receives or otherwise identifies scheduled eventand device inputs. These are designated in the drawing as S2 and i2,respectively. Specifically, a scheduled event thread identifies andobtains generated/queued event S2 and checks them against eventconstraints, e.g., stored in the production support database 18 b″. AnI/O event thread likewise identifies and obtains generated/queued deviceinputs i2 and checks them against constraints in the production supportdatabase 18 b″. If the events S2 or inputs i2 match the constraints,they are queued in an internal trigger queue for processing. These aredesignated in the drawing T1, the letter “T” indicating that they aretriggers.

[0339] The triggers are, in turn, queued in an internal trigger queuefor processing. These are taken up on a FIFO or other basis by an actionexecution thread (“AET”) also executing in the event manager 18 a. Onesuch trigger is designated T2 in the drawing. The action executionthread processes the trigger in accord with the workflow, particularly,for example, executing the event action(s) associated with theparticular current trigger (here, trigger T2). As noted previously,those actions can include transactions (such as start, complete, etc.)to be executed by the client applications 12-16, storedprocedures/database actions, and so forth.

[0340] As discussed above in connection with FIG. 6, the actionexecution thread queues messages to those applications, here designatedT3 a, T2 b, reflecting that a single trigger executed by the eventmanager 18 a (and, particularly, the action execution thread) may resultin generation of more than one message for processing by the clients12-16.

[0341] With continued reference to FIG. 7, the event manager 18 aincludes an expression evaluation thread to process expressions inresponse to requests issued by the client applications. Here, a requestX1 for expression evaluation is generated by a client application andqueued or otherwise transmitted for processing by the manager 18 a. Therequest is dequeued or otherwise received by the manager's 18 aexpression evaluation thread, which parses or otherwise interprets therequest, generating a response (e.g., based on current system statevalues) for return to the requesting application. Here, that response isdesignated X2 and is shown being queued, e.g., in the manner detailed inFIG. 6 and discussed above, for return to that application. Duringprocessing of an expression X1, additional messages (not shown) can begenerated and queued to the client applications, e.g., to obtain furthervalues necessary to evaluate the expression.

[0342] The event manager 18 a also includes an administrative commandevaluation thread that processes commands received, for example, fromthe operator console. As above, one such command, here, designated A1,generated by the console is queued or otherwise transmitted forprocessing by the event manager 18 a. That request is dequeued orotherwise received by the command evaluation thread, which parses orotherwise interprets it, altering internal system states, generatingoutput, or performing such processing as is desirable or necessasry inview of the command. It will be appreciated that, though not illustratedhere, such processing may include generation of messages to the clientapplications 12-16, e.g., as discussed above in connection with theexpression evaluation and action execution threads.

[0343]FIG. 8 also depicts event processing in an event manager 18 aaccording to one practice of the invention—here, however, in anembodiment or instance where there is persistence in data flows. Asshown in this illustration, operation of the event manager proceeds asdescribed above in connection with FIG. 7. Rather than a single actionexecution thread (AET), a pool is shown in this drawing. Each AET in thepool operates as described above, taking up processing of the triggers(here shown being queued to an additional queue, the internal actionqueue) as the respective AET becomes available.

[0344] Process Data Items

[0345] The configuration manager integrates information generated byoperation of system 10 and its constituent components using Process DataItems (PDIs). These can be established to collect information, triggeractions, and activate messages. These are also used to process valuesthat are maintained or managed by the system.

[0346] PDIs can be associated with equipment or locations, and also candepend, for example, on materials to determine appropriate SPC targetsand limits. The source of PDI values can be an I/O source. For example,basic information coming from the PLC or other I/O source, such as rollcount, is used to trigger tags (PDIs). For example, a roll is completedevery time 500 units are processed and a test is required after everyfive rolls. The following tags would be established:

[0347] At multiples of 500, the “Roll Finished” tag would be generatedand stored in the database.

[0348] Every 5 rolls (5×500), an action will be triggered. If theoperator is required to enter specific information, this action couldinclude a trigger.

[0349] Additional on/off triggers would be used to generate warningmessages, alarms, and other important information.

[0350] PDI values can also be derived from an expression calculated fromother PDIs. In either event, limits and scaling are similar to those forprocess control tags. Extensions to process data items includecollection plans, events and messages. These enable the grouping ofprocess data items so they can be captured as a single event, eitherautomatically, manually, or in combination. FIG. 9 depicts anobject-oriented class structure supporting, among other things, PDIs andcollection plans in a system according one practice of the invention.

[0351] Types of PDIs supported by the illustratred embodiment includedate/time, discrete, list, numerical and text, as described above.

[0352] List PDIs.

[0353] A list PDI is a process data item or tag that stores a positionin a hierarchical tree. The tree in the database schema is a circularreference (references itself) so that it can be easier to store in thedatabase. The database structure can be seen in FIG. 10. The tree iscreated with the configuration client and an example can be seen in FIG.11.

[0354] Jump points, elements 1308 and 1310 of FIG. 13, associated withthe List PDIs that can be seen from FIG. 11 (in brackets). These jumppoints are globally unique to the database and allow easy navigation tothe exact node they reference. The node does not require a jump pointthough so level names must be unique for each list PDI. Each list PDIcan have a different tree. In the illustrated embodiment, the entiretree is not stored with the tag, just the final location. In order toset the list PDI, a user is presented with a list in order to make achoice as to which node the list PDI is going to point to. In theillustrated embodiment, this is handled by a List Manager.

[0355] Note from FIG. 10, than any list node (ListElement Table) canhave a ParentIndex. This parent index points to another node in theListElement table, which is where the circular reference is used.

[0356] The anatomy of a list PDI is illustrated by FIG. 12. As suggestedthere, every list in the illustrated embodiment has one and only one“Root” element. In the illustrated embodiment, during runtime, a usercan only select a “Terminating” element. “Jump Point” identifiers arepreferably unique across the entire system since they indicate both alist and a location within that specific list.

[0357]FIG. 13 illustrates a simplified standard list PDI 1302 of thetype used in a system according to the invention. Standard PDIs, like1302, are a subclass of PDIs that group general properties together,serving as templates for individual PDIs or instances.

[0358] The illustrated PDI defines a hierarchical relationship betweenthe term “electrical” and the terms “light,” “motor,” and “switch,” asillustrated. It further defines a hierarchical relationship between theterm “motor” and the terms “rotor failure,” “bushing burnout” and “fusefailure.” Such a PDI can be used to reflect a real-world (or other)relationship, for example, between the electrical system of ahypothetical plant or control system and its major constitutents, towit, the light, motor and switch. It can likewise reflect, to continuethe example, modes of failure of those constituents—here, rotor failureor bushing burnout of the motor. In practice, a standard PDI may includemore nodes than illustrated PDI 1302.

[0359] PDI instances can be created ad hoc as illustrated by element1304. This PDI defines a hierarchical relationship between the term“plant 1” and the terms “catastrophic failure” and “mechanical.” Itfurther defines a hierarchical relationship between the term“mechanical” and terms “belt broke” and “rivet failed.” Such a PDI canbe used to reflect a real-world (or other) relationship, for example,between a plant (here, “plant 1”) or control system and its the failuremodes (here, “mechanical” and “catastrophic failure”). It can furtherreflect, to continue the example, the causes of those failures (here,“belt broke” or “rivet failed” as types of mechanical failure). Again,in practice, a standard PDI may include more nodes than illustrated PDI1302.

[0360] PDI instances can also contain or be created (solely orotherwise) from standard PDIs, as illustrated by element 1306. This PDI1306 combines the hierarchical relationship defined in 1302 and 1304 asindicated in the drawing. For convenient viewing, the relationshipstaken from standard PDI 1302 are indicated by dashed lines.

[0361] The illustrated PDIs 1304, 1306 further include jump points,designated 1308 (with a value “112”) and 1810 (with a value “4938”).These are effectively short-cuts that permit the user to quicklyidentify an element in a potentially large or complex hierarchical list.For example, the value “112”can be used, e.g., when defining displaysbased on the list PDI 1304, as a reference (e.g., which can be quicklyinput by the user or system engineer) to plant 1/mechanical/belt brokenode of list PDI 1304. Likewise, the value 4938 can be used as areference to the plant 1/electrical/motor/rotor failure node of list PDI1306.

[0362] The components and uses of list PDIs may be better understood byreference to the graphical user interface (GUI) screens/panels throughwhich they are maintained in the illustrated embodiment. It will beappreciated that list PDIs in other embodiments may have componentsother than those shown here, and they may be maintained other than viathe illustrated GUI screens. In the illustrated embodiment, threemaintenance panels are provided. General (see FIG. 14A), List Definition(see FIG. 14B), and Dependencies (see FIG. 14C).

[0363] Referring to FIG. 14A, the General panel is used to maintain thename of the PDI, assign the machine or location for which data will beretrieved, and define general names for the levels created on the LevelDefinition screen.

[0364] The General panel includes the following fields: PDI Name The PDIname is assigned when the PDI is created. Description A detaileddescription of the PDI. Machine Association Associate the listed PDI toan existing machine. The data processed is linked to the machine in alloperations. List PDIs can be used to collect free-form comments about amachine from a Runtime user. Location Association Associate the list PDIto an existing location. The data processed is linked to the location inall operations. Level Name After lists and sublists of PDI text arecreated, the user can assign general labels to the levels.

[0365] Referring to FIG. 14B, the List Definition window is used toassign the lists and sub-lists of elements. Lists of text elements arecreated in a tree formation (parent-child1-child2, etc.), with up to tensub levels.

[0366] A right-click menu is available on the List Members table. Afterselecting an element, click the right mouse button to display a list ofedit options: Add Element—to add a new element on the next sublevelbelow the selected element. Edit Element—to edit the details for theselected element. Remove Element—to remove the selected element. MoveUp—to move the selected element above the previous element at the samelevel. Move Down—to move the selected element below the next element atthe same level.

[0367] The List Definition panel includes the following fields: StandardList Templates Copy all the elements from a Standard List PDI. ExistingList Elements Shows all the current items available for the PDI.Selected List Elements Build a tree of up to ten levels of list PDIs.The name of the Table PDI is shown as the top (level). Add ElementReferring to the Edit List Element dialog box of Figure 12B, to add anew element, the user selects the element under which the element willbe placed as a subelement. Content The element text. New ElementCheckbox used to signify adding a new element. Jump Point A jump pointallows the user to move quickly to the element on the list by typing thefirst letter(s) of the name. In the illustrated embodiment, jump pointsmust be unique within the same list. Edit Element To change the settingsfor an element, click the element in the display table. Click Edit oruse the right-click menu to access the Edit List Element window for theelement. Change the text or jump point in the window as needed.

[0368] Referring to FIG. 14C, the Dependencies panel of the List PDIsmaintenance screen displays all objects to which the PDI has beenassigned.

[0369] List Manager API

[0370] In the illustrated embodiment, the list manager provides thefunctions described below.

[0371] INode

[0372] The INode interface is the connection to the Node object. Listedbelow are the Node object properties.

[0373] Get_DescIndex

[0374] Description: Retrieves the Description Index (StringID) of theNode.

[0375] Syntax: STDMETHODIMP get_DescIndex(long *pVal) Parameters InputParameter Description pVal Returned Description of Index of node. ReturnCode Return Code Description HRESULT Success or failure of property get.

[0376] Get_Description

[0377] Description: Retrieves the Description (StringText) of the Node.

[0378] Syntax: STDMETHODIMP get_Description(BSTR *pVal) Parameters InputParameter Description pVal Returned Description of node. Return CodeReturn Code Description HRESULT Success or failure of property get.

[0379] Get_IsTerminalNode

[0380] Description: Returns if the Node is a terminal node (leaf) of alist.

[0381] Syntax: STDMETHODIMP get_IsTerminalNode(VARIANT_BOOL *pVal)Parameters Input Parameter Description pVal Returns True if a terminalnode, false otherwise. Return Code Return Code Description HRESULTSuccess or failure of property get.

[0382] Get_ListIndex

[0383] Description: Retrieves the List Index (ListElementIndex) of theNode.

[0384] Syntax: STDMETHODIMP get_ListIndex(long *pVal) Parameters InputParameter Description pVal Returned List Index of node. Return CodeReturn Code Description HRESULT Success or failure of property get.

[0385] Get_PDIObjectIndex

[0386] Description: Retrieves the PDIObjectlndex of the Node.

[0387] Syntax: STDMETHODIMP get_PDIObjectIndex(long *pVal) ParametersInput Parameter Description pVal Returned PDIObjectIndex of node. ReturnCode Return Code Description HRESULT Success or failure of property get.

[0388] INodes

[0389] The INodes interface is the connection to the Nodes collectionobject. Listed below are the Nodes object properties

[0390] Get_Count

[0391] Description: Retrieves the number of Node objects contained inthe Nodes collection.

[0392] Syntax: STDMETHODIMP get_Count(long *pVal) Parameters InputParameter Description pVal Returned count. Return Code Return CodeDescription HRESULT Success or failure of property get.

[0393] Get_Item

[0394] Description: Retrieves a specific Node object contained in aNodes collection. The object can be returned with either a ListIndex ora Description.

[0395] Syntax: STDMETHODIMP get_Item(VARIANT vntIndex, INode **item)Parameters Input Parameter Description vntIndex Either a long(ListIndex) or a BSTR (Description) for the retrieval of the node. itemThe returned INode object. Return Code Return Code Description HRESULTSuccess or failure of property get.

[0396] GetDescriptionIndexVector

[0397] Description: Retrieves the first 10 StringIDs of a NodesCollection for C++ implementations.

[0398] Syntax: STDMETHODIMP GetDescriptionIndexVector(long vals[10])Parameters Input Parameter Description vals[10] Returned array ofStringIDs Return Code Return Code Description HRESULT Success or failureof property get.

[0399] INodeMgr

[0400] The INodeMgr interface is the link between the Node object, theNodes collection and the database. The functions are listed below.

[0401] GetNode

[0402] Description: Returns a Node object given a valid StringID andLanguageID for the Node to return.

[0403] Syntax: STDMETHODIMP GetNode(long nStringID, long nLangID, INode**item) Parameters Input Parameter Description nStringID StringID ofnode to retrieve. nLangID Language ID item The returned INode object.Return Code Return Code Description HRESULT Success or failure ofproperty get.

[0404] GetNodeElements

[0405] Description: Returns a Nodes collection of child nodes given avalid parent node.

[0406] Syntax: STDMETHODIMP GetNodeElements(INode * item, long nLangID,INodes **items) Parameters Input Parameter Description item Parent Nodeto retrieve children. nLangID Language ID items The returned INodescollection Return Code Return Code Description HRESULT Success orfailure of property get.

[0407] GetNodePath

[0408] Description: Returns a Nodes collection of the path from a jumppoint to the parent node.

[0409] Syntax: STDMETHODIMP GetNodePath(long nJumpPoint, long nLangID,INodes **items) Parameters Input Parameter Description nJumpPoint JumpPoint to retrieve path. nLangID Language ID items The returned INodescollection Return Code Return Code Description HRESULT Success orfailure of property get.

[0410] GetPath

[0411] Description: Returns a Nodes collection of the path from asupplied node to the parent node.

[0412] Syntax: STDMETHODIMP GetNodePath(INode * item, long nLangID,INodes **items) Parameters Input Parameter Description item Node toretrieve path nLangID Language ID items The returned INodes collectionReturn Code Return Code Description HRESULT Success or failure ofproperty get.

[0413] GetRootNodes

[0414] Description: Returns a Nodes collection of the Parent nodes of aspecific PDIObjectIndex.

[0415] Syntax: STDMETHODIMP GetRootNodes(long nPDIObjectlndex, longnLangID, INodes **items) Parameters Input Parameter DescriptionnPDIObjectIndex PDIObjectIndex of object to retrieve parent nodesnlangID Language ID items The returned INodes collection Return CodeReturn Code Description HRESULT Success or failure of property get.

[0416] List API Usage

[0417] Using the API described above, a list PDI class can be defined isgenerally indicated below: class CListNode{ // Jump Point identifier intm_iUserDefinedIndex; // Array of text for element // Array entriesrepresent text for different locales. _bstr[] m_szElementText; // Indexinto StringConversion table int m_iElementTextIndex; // Is this aterminating node? boolm_bTerminating; };

[0418] Such a class exposes the methods CListNodesGetChildElements(CListNode * pParentNode) and CListNodesGetPathElements(int iJumpPoint).

[0419] Examples of usage of exposed methods include the following:

[0420] 1) cNodes=GetChildElements((CListNode *) NULL);

[0421] Resulting “cNodes” Collection:

[0422] cNodes==>“Electrical”

[0423] 2) Continuing the example from above, we make this subsequentcall:

[0424] cNodes=GetChildElements(cNodes[0]);

[0425] cNodes==>“Light”

[0426] “Motor”

[0427] “Switch”

[0428] 3) cNodes=GetPathElements(2112);

[0429] Resulting “cNodes” Collection:

[0430] cNodes==>“Electrical”

[0431] “Motor”

[0432] “Bushing Burnout”

[0433] In the illustrated embodiment, the configuration manager 18 gmanages process data items (PDIs). The configuration client allows theuser to configure them. PDIs are supported through data maintained inthe InTrack database 12 b, including work-in-progress tracking andresource tracking, and represent tag in the aforementioned InTouchapplication. If any of the historization attributes are selected, thePDI also represents a tag in the aforementioned InSQL application. Oncea tag is configured and saved, the interpreter 18 d is executed whichtransfers the appropriate attributes to the InTouch tag database andInSQL database. The configuration client permits security groups, usersand associated passwords to be created. Once the user information issaved, execution of the interpreter will transfer the securityinformation to the aforementioned InTrack application.

[0434] Collection Plans

[0435] Collection plans are used to collect run-time data. They can beautomatic, partially automatic, or manual. In the illustratedembodiment, automatic collection plans are evaluated by the actionexecution thread (see FIG. 7) and stored to the inTrack database 12 b.Partially automatic and manual collection plans are transmitted to therun-time clients 18 e, 18 f for evaluation.

[0436] To that end, messsages for those plans are sent via the commonrun-time client queue (see FIG. 7). Each collection plan is recorded asa single item of delivery. It is triggered on the node assigned in theConfiguration Client. The Event Manager reads the incoming tag, andplaces the collection plan into the queue where it can be accessed fromthe Runtime Client. All computers assigned to the workstation groupreceive the collection plan. The collection plan appears on the tasklists of the runtime clients 18 e, 18 f, where it can be accessed andcompleted. Depending on the set-up, the collection plan is generatedafter a certain amount of time, an action, certain measurement of units,etc., based on the triggers assigned to the collection plan orproperties assigned to the PDI. If the tag is configured for SPC tags,SPC tags can generate an alarm. The Event Manager saves messages on thequeue to the InTrack database along with the collection time.

[0437] The runtime clients 18 e, 18 f allows operators to enter dataresponsive to those messages for entry into the respective plans. Manualcollection plans appear on task lists for assigned workstationsassociated with the run-time clients 18 e, 18 f. When opened, entrygrids enable operators to enter information for each PDI in thecollection plan. This data is stored in the databases. The illustratedembodiment also permits stored procedures to be included in collectionplans: as the collection plans are opened and saved, additionalactivities such as calculations or communication with other resourcescan be executed.

[0438] Collection plans can be based on templates that serve as outlinesor basic patterns. For example, if a user wishes to establish sixdifferent product quality tests with the same types of measurements, heor she can enter the basic collection items in a template. Whenindividual collection plans are created from the template, the userassigns individual parameters to the measurements as needed. In theillustrated embodiment, collection plan templates are optional: the usercan create individual collection plans without them.

[0439] In the illustrated embodiment, collection plans are a superset ofInTrack data collection, that is, of the data collection maintained bythe inTrack application 12 a and stored in the associated database 12 b.In this regard, the InTrack application 12 a provides the mechanism tostore and retrieve a tine stamped series of user definable records andcolumns. (Of course, it will be appreciated that other functionality,standard in the art, proprietary, or otherwise, could be used for thispurpose in place of the InTrack application). The configuration managerand client permits the user to specify collection plan objects linkingInTrack data collection items to PDIs (external data points) andexpressions. They also allow the user to define specific items ofinformation to be collected per location or machine. Collection planactions can also be dropped into workflows.

[0440] When the user saves a collection plan and runs the interpreter 18d, the aforementioned automation server creates the data collection,using machine and location attributes available on the collection planand other objects available within production engine. Specifiedattributes are created within the InTrack application 12 a after runningthe interpreter 18 d.

[0441] Once saved and interpreted, the engine executes workflows as theyare triggered. When the collection plan action is executed the enginegathers the appropriate external data storing them to collection items,performs the configured calculations using other collection items andstores the values using calls to the data set object of the InTrackautomation server.

[0442] The expression assignment capability is provided, in theillustrated embodiment, via the GEO application, though, othermechanisms standard in the art, proprietary or otherwise can be usedinstead or in addition. At runtime, each expression is evaluated,including the specified item parameters as input. The result is storedas the collection plan item specifying the expression.

[0443] The illustrated system also provides for “stored procedures incollection plans”. These allows the user to insert one or more storedprocedure calls into the collection plans. These stored procedures areexecuted using ADO. Each collection plan item, specified for use in thestored procedure, are loaded as parameters into the ADO object and theappropriate stored procedure is executed. All collection plan items arewritten to InTrack via the automation server once all items areevaluated.

[0444] Active Client Control

[0445] Described below is the ActiveClient control used by runtimeclients 18 e, 18 f according to one practice of the invention to createand edit collection plan records. The control is implemented into theruntime clients to allow users the ability to view queued items, as wellas templates for creating new records. The control is also be defined todisplay archived collection plan records according to a user definequery filter.

[0446] In the illustrated embodiment, two modes are defined for the userto view and edit collection plan records; “View” and “Edit”. Threepanels are defined to display to the user; the tasks available, therecords associated to the selected task, and the selected task items forediting. A separate panel is defined to allow the user the ability tofilter the returned collection plan records.

[0447] View Mode

[0448] Referring to FIG. 15, this is the view the user sees in theillustrated embodiment when no edits are being performed. Collectionplans are indicated at the top of the view panel, here, entitledAuto_All_Items and Man_All_Items. Depending on which is selected, here,the latter, the data collection tasks that make that plan up areindicated on the bottom of the view panel. Here, the tasks areidentified by sample (or task) i.d., sample time, collection time,status, comments, superceded, and sample duration, among others. Queuedplans are supplied via MSMQ. The displayed task list can be filtered orsorted, as desired by the user. Of course, in other embodimentsdifferent views, graphical or otherwise, may be presented.

[0449]FIG. 16 depicts the view the user sees during edit mode of theillustrated embodiment. There are three types of edit mode:

[0450] New collection plan record from a template item

[0451] Edit collection plan record from a queued item

[0452] Edit collection plan record from an archived item

[0453] New Collection Plan from a Template

[0454] In the illustrated embodiment, entering edit mode through atemplate item creates a new collection plan record. This templatesupports automatic and manual items. Manual items require user input. Ageneric default value is stored initially into the field upon enteringedit mode, unless a specific default value had been configured.Automatic items are populated by retrieving values from a tag server. Ifthe tag server is not available, default values are used as with manualitems. Automatic items are not editable by the user, unless they weredefined as a datetime with the name of “SampleTime”, or as a list item.

[0455] Edit Collection Plan Record from a Queue Item

[0456] Entering edit mode through a queued task item removes the itemfrom the common message queue folder. This prevents all other configuredusers from accessing this item. This record is stored in a separatedatabase table until all required items have been supplied by the user,and the task list displays this item as “InWork” with the use of adistinct icon. Upon completion of all required items, the task isremoved from the task list, the stored record is removed, and thecollection plan record status is updated to the appropriate statusindicator.

[0457] Edit Collection Plan Record from an Archived Item

[0458] After a queued task has been completed, and the item has beenremoved from the task list, the user can still edit the record by way ofthe Collection Plan Samples grid (defined below).

[0459] Collection Plan Samples

[0460] A grid is defined to display all collection plan recordsaccording to the user defined query criteria. This is performed when theuser configures the QBE, and by selecting a task in the task list. Allconfigured data items within the collection plan record are supplied inthe grid, as well as all relevant base InTrack table items: such asStatus, SampleTime, SampleID, etc. During edit mode, manual andautomatic items have specific characteristics. The following sectiondescribes the characteristics.

[0461] Automated Items

[0462] Upon entering edit mode, automatic items are populated with thevalues from the tag server only when the user has selected a collectionplan template for creating a new record. Otherwise, the Event Managersupplies the automatic items through a queued collection plan record tothe client, or previously by a client creating a new sample through atemplate. In the illustrated embodiment, after the record has beencreated and saved, no automatic items are editable, except for thefollowing: collection plan items configured as a Datetime item, andconfigured with the item name “SampleTime” and any list item.

[0463] Manual Items

[0464] Upon entering edit mode, any manual item is made available forediting. This is true for new records, queued records, or archiverecords.

[0465] Data Types

[0466] In the illustrated embodiment, a collection plan can include thefollowing data types:

[0467] Date/Time

[0468] In the illustrated embodiment, a datetime PDI (or tag) is definedas an item to represent a date and time value. Datetime items can beconfigured with a default value representing any valid date and time.

[0469] Discrete

[0470] In the illustrated embodiment, a discrete PDI (or tag) is definedas an item to represent a “True” or “False” condition. This value can bedisplayed with a textual value such as “On” or “Off”, as well as anyother desired combination. Discrete items can be configured with adefault value representing either a “True” of “False” value.

[0471] List Items

[0472] As evident in the discussion above, a list PDI (or tag) is anitem that stores a position in a hierarchical tree. In the illustratedembodiment, the tree in the database schema is a circular reference(references itself) so that it can be easier to store in the database.

[0473] Numeric

[0474] In the illustrated embodiment, a numeric PDI (or tag) is definedas an item to represent any valid numeric value. Numeric items can beconfigured with a default value representing any valid numeric value.

[0475] Stored Procedure

[0476] In the illustrated embodiment, a stored procedure PDI (or tag) isdefined as an item to represent any valid stored procedure interface.This item allows the user to supply information to return furtherinformation through a stored procedure. FIG. 17 illustrates arelationship among classes defining the production support database 18b″ and those defining stored procedure items stored procedure items(identified by dashed lines). Items in the drawing shown in boldfacetype are returned in the stored procedure. Nullable items are returnedas zero for null string, as appropriate. Edit classes are designatedwith an E; stored procedure item classes with a I; and stored procedureclasses with a S.

[0477] Text

[0478] In the illustrated embodiment, a text PDI (or tag) is defined asan item to represent a textual value. Text items can be configured witha default value representing any value.

[0479] Collection Plan Execution Implementation

[0480] Event Manager

[0481] In the illustrated embodiment, the event manager and runtimeclient (RTC) nodes work together to create collection plan data.Initially, the collection plan initiated. If it is an automaticcollection plan then the RTC has no interaction. If it is a manualcollection plan then the RTC supplies Event Manager with some or all ofthe collection plan data. To initiate the collection plan, a trigger isrequired. The collection plan is either a manual or automatic collectionplan as described below.

[0482] Automatic Collection Plan

[0483] When the trigger is fired, the event manager fills in the datafor the collection plan. This is saved using one of the controlapplications 12-16 and, specifically, in the illustrated embodiment, thedata collection method of the aforementioned InTrack application(though, it will be appreciated, that data collection methods of othercontrol applications, industry standard, proprietary or otherwise, maybe used in addition or instead).

[0484] Manual Collection Plan

[0485] First, the event manager fills what data it can in the collectionplan with the automatically collected items and then calls the InTrack(or, as indicated in the prior paragraph, other application) datacollect method. In the illustrated embodiment, a message is sent to theMicrosoft Message Queue server with the data in a ADO recordset. Thismessage is directed to one or more real time clients (RTC). The RTC(s)read(s) this message and the user fills in some or all of the data forthe collection plan. This data is then sent back to Event Manager viaanother message. Event Manager calls as method from the DSSManager whichupdates the previous InTrack data collection data using InTrack's datacollection supercede.

[0486] Collection Plan Stored Procedures

[0487] Stored procedures are fully operable for both collection plansand actions in the illustrated system. Entry options in theconfiguration client to enable fast entry of connection information andstored procedure parameters and commands.

[0488] Stored procedures are activated series of commands that aretriggered when a collection plan or action is conducted in Runtime.Trigger conditions determine if and when the stored procedure isactivated. Stored procedures can be used to:

[0489] Generate displays of numerical values or text to operators.

[0490] Calculate numerical values from ongoing measurements (PDIs) fordisplay during Runtime, storage in the database, or download to PLCs.

[0491] Perform comparisons of multiple data inputs to generate resultsthat may trigger additional activities, such as value conversion(English/metric), storage of data in multiple databases, or generationof PDIs to control a PLC or machine. In addition, stored procedures canbe nested so that multiple stored procedures are activated in tandemwithin the same collection plan. A stored procedure can generate anoutput value that will be used immediately as an input value in a secondstored procedure. Collection plan stored procedures supports a varietyof SQL data types:

[0492] Configuration Entry Screens

[0493] Entry screens and display windows accommodate entry of storedprocedure connection and command information. List windows enableselection and display of existing stored procedures. As stored procedureinformation is entered, default input and output item names are assignedautomatically, selection options enable the configuration of items, andSQL script validation is performed. Entry screens have beenstandardized, enabling fast reference and selection of stored proceduresactivated by any combination of multiple collection plans and actions.

[0494] Collection Plan Template Maintenance Screen

[0495] In the illustrated embodiment, after a new collection plantemplate is selected for editing, a collection plan template maintenancescreen appears. See, FIG. 18. The General panel is used to maintain thename and description of the collection plan template. An example of itis provided in FIG. 19. The PDI selection panel stores information abouteach PDI that appears as an entry field on collection plans generatedfrom the template. See FIG. 20. This can be used to specify the type ofPDI and basic information. The dependencies panel lists all objects thatare dependent on the current collection plan template.

[0496] Config & ProdSupport Common Tables

[0497] The following tables are common to both the Configuration andProduction Support databases in support of Collection Plans in theillustrated embodiment.

[0498] Action

[0499] In the illustrated embodiment, the Action table identifiesActions in the illustrated system. Actions may be one of several typesindicated by the ActionType field. Field Name Field Format FieldDescription ActionIndex Int NOT NULL (Primary Unique Index Key)ActionName Varchar(30) NOT NULL Name of Action (unique) Description IntNULL Points to a multi-lingual text description of the Action, usingStringConversion.StringID ActionType Tinyint NULL Type of Action: 1 =Collection Plan 2 = Production Event 3 = Process Message (Msg Port) 4 =Expression 5 = E-mail 6 = SQL Statement SecurityType Int NULL Describesthe type of security check done for operators executing the action (Usedfor CollectionPLans and Production Events mainly) 1 = Use Login UserID 2= Always prompt user for UserID/Password check (every transaction)

[0500] CollectionItem

[0501] In the illustrated embodiment, this table identifies individualitems to be collected as part of a Collection Template. Each itemidentifies a “slot” in the collection plan. Multiple collection plansmay share the same Collection Template and therefore the same set ofCollectionItems. Field Name Field Format Field DescriptionCollectionItemIndex Int NOT NULL (PK) Unique IndexCollectionTemplateIndex Int NOT NULL FK to CollectionTemplate ItemNumberIn NOT NULL Unique within the template, this field orders the itemssequentially HeaderItem Bit NOT NULL TRUE when the item is in the Headersection of the plan. CollectionItemName Varchar(30) NOT Unique withinthe template this NULL names the columns used in the collection plan(used by InTrack to name the DataSet Items for the DS Template) PDITypeTinyint NOT NULL Type of PDI (see PDIObject)

[0502] CollectionPDI

[0503] In the illustrated embodiment, this table lists the specific PDIsthat are mapped to CollectionItems for each Collection Plan.CollectionItemIndex Int NOT NULL (PK) FK to CollectionItem ActionIndexInt NOT NULL (PK) FK to CollectionPlan (Action) PDIObjectIndex Int NULLFK to PDIObject identifies the PDI to map to the collection item forthis collection plan Automatic Bit NOT NULL TRUE when the PDI value iscollected automatically by EventMgr. False means the value is manuallycollected by operator. Required Bit NOT NULL TRUE when the operator isrequired to enter a value for this item. False means data entry isoptional. Description Int NULL Pointer to StringID in StringConversiontable. Optionally describes the PDI/CollectionItem relationship.Expression Varchar(120) Text expression to be used by Run-Time clientfor automatically filling in the item with the result of an expressionbased on values of other entered items. DefaultValue Varchar(30) NULLDefault value for the CollectionPDI when filled in by EventMgr, o whenpresented to operator for manual collection. This is a formatted floatfor numeric PDIs.

[0504] CollectionPlan

[0505] In the illustrated embodiment, this table is 1:1 with Actionwhere ActionType=1 Field Name Field Format Field Description ActionIndexInt NOT NULL (PK) FK to Action CollectionTemplateIndex Int NULL FK toCollectionTemplate PlanType Int NULL Type of Collection Plan: 1 = Manual2 = Manual Standard 3 = Automatic 4 = Automatic Standard 5 = Combo 6 =Combo Standard Lifecycle Int NULL Expiration time in minutes for theCollection plan to be fulfilled. LocationIndex Int NULL FK to Locationtable. Optionally associates the Collection plan to a location.MachineIndex Int NULL FK to Machine Table. Optionally associates theCollection plan to a machine.

[0506] CollectionTemplate Field Name Field Format Field DescriptionCollectionTemplateIndex Int NOT NULL (PK) Unique IndexEstablishingStandard Identifies the Collection A Collection Template isplan (standard or non-standard) shared by all regular Cplans whichcreated the linked to a standard. This CollectionTemplate fieldidentifies which Cplan is the standard that created it. It alsoidentifies the regular Cplan when it is independently configured (doesnot use a standard)

[0507] ControlItem

[0508] This table identifies target and limit sets by PDI, ProductGroup, and Effective date. Field Name Field Format Field DescriptionControlSetIndex Int NOT NULL (PK) FK to ControlSet EffectivityDateDatetime NOT NULL Date the target and limit set is (PK) to take effect.MaterialGroupIndex Int NOT NULL (PK) FK to MaterialGroup. Identifies theMaterial (Product) Group for the target/limit set. Description Int NULLPointer to StringID in the StringConversion table. Target Float NOT NULLThe target value for SPC analysis CL Float NOT NULL The Control Limitmean for SPC analysis USL Float NOT NULL Upper Specification Limit UCLFloat NOT NULL Upper Control Limit LCL Float NOT NULL Lower ControlLimit LSL Float NOT NULL Lower Specification Limit Rmean Float NULLExpected mean value for Range RUCL Float NULL Upper Control Limit onRange RLCL Float NULL Lower Control Limit on Range

[0509] ControlSet

[0510] In the illustrated embodiment, the table groups the target andlimit sets given by the ControlItem table into sets for standardization.Every PDI for SPC analysis has a ControlSet. This can be standardized sothat several PDI may share the same control set. Field Name Field FormatField Description ControlSetIndex Int NOT NULL (PK) Unique IndexEstablishingStandard Int NULL Identifies the PDI

[0511] UI Messaging

[0512] The UI Messaging mechanism of the illustrated embodiment providesfor definition of a user interface—i.e., prompts, questions,text/list/combo boxes, and so forth—through which information ispresented to, and accepted from, the operator, e.g., via real-timeclients 18 e, 18 f and via applications 12-16 which understand the UImessage format. The UI mechanism also provides the ability to associateelements of the presented user interface with variables (e.g., PDIs) inthe system 18, as well as the ability to programmatically extractuser-entered results from the UI Message for use in other parts of theexecution context, e.g., as workflow variables.

[0513] Configuration of UI Messages is accomplished using theconfiguration client, e.g., database 18 b and editor 18 c. Theconfiguration client of the illustrated embodiment utilizes displays asshown in FIGS. 28-29 for this purpose. Referring to FIG. 28, a screensuch as shown there is used in the illustrated embodiment to permitgeneral definition of a UI message—here, a message named PROMPT1, with adescription DESCRIPTION1, heading HEADING 1, a timeout of 120 seconds,and workstation specifier of ALL. Of course, in practice moredescriptive terms are likely to be used for each of the description andheading fields, as well as for the message name. The timeout period,shown here as defaulting to 120 seconds, specifies the period afterwhich the message will be returned to the queue and removed, if theoperator fails to open the message. The workstation specifier indicateson which workstations the message is valid.

[0514] Referring to FIG. 29, a screen such as shown there, provides fordefinition of the message items that make up the UI message. Dependingupon implementation and on the demands of the workflows that invoke theUI message actions, each message item can be treated as a separate UImessage; alternatively, groups of one or more message items can be sotreated. Shown here is a first message (Seq. Num. 1), with a prompt“Enter number,” for entering a value into a specified number-type PDI.One or more of these messages can be identified as “required,” asindicated by the check-box field, also shown in the drawing. Thoseskilled in the art will appreciate that FIGS. 28-29 are merely examplesof interfaces that permit a design or configuration engineer to specifya UI message in a system according to the invention.

[0515] The configuration client stores data that makes up a UI Messagein three tables in the configuration database 18 b:

[0516] UIMessage

[0517] UIMessageTransforms

[0518] UIMessageItems

[0519] These tables are created via an SQL commands as follows, thoughit will be appreciated that such tables may be created elsewise and thatthey may be represented, instead or in addition, by structures otherthan tables (e.g., hierarchical databases, linked lists, objects orobject databases, and so forth). It will also be appreciated that thefields other than those shown in the following SQL commands may be usedin the tables instead or in addition. CREATE TABLE UIMessage {ActionIndex int NOT NULL, Heading varchar(256) NULL, Timeout long NOTNULL, UITransformIndex int NOT NULL, PRIMARY KEY (ActionIndex), FOREIGNKEY (ActionIndex) REFERENCES Action FOREIGN KEY (UITransformIndex)REFERENCE UIMessageTransforms } CREATE TABLE UIMessageTransforms {UITransformIndex int NOT NULL, UIStyle text NOT NULL, PRIMARY KEY(UITransformIndex) } CREATE TABLE UIMessageItems ( ActionIndex int NOTNULL, SequenceNumber int NOT NULL, Message varchar(256) NOT NULL,PDIObjectIndex int NULL, UIType int NOT NULL, Required bit, PRIMARY KEY(ActionIndex, SequenceNumber), FOREIGN KEY (ActionIndex) REFERENCESUserPrompt, FOREIGN KEY (PDIObjectIndex) REFERENCES PDIObject )

[0520] The data in the respective UIMessage tables is moved into theruntime execution environment when the interpreter 18 d is executed. Atthat point, all UI Message data available in the production supportdatabase 18 b″, using an identical schema to that shown above.

[0521] In the illustrated embodiment, UI Messages are implemented asactions; hence, all activity on them is initiated by the Event Manager.A UI Message “action” may be part of a workflow and/or otherwiseassociated with a data change event, an alarm event, a scheduled event,or otherwise. FIG. 30 depicts the sequence executed in the illustratedembodiment when such a UI Message action is executed in response tooccurrence of the corresponding event.

[0522] A IUIMessage component is provided by the system to facilitateprocessing of UI Messages by the AET and by the runtime clients. TheIUIMessage component is a DLL which provides the following interface andwhich has the following functionality. interface IUIMessage {// METHODS: // load from Production Support tables into internal formatHRESULT Load (CComBSTR& ConnString); // convert entire UIMessage to XMLformat HRESULT ToXML (BSTR* Message); // convert entire UIMessage fromXML format HRESULT FromXML (BSTR Message); // get/set Result Value dataHRESULT SetResultValue (BSTR Name, VARIANT Value); HRESULTGetResultValue (BSTR Name, VARIANT* Value); // get/set Body elementsub-tree HRESULT GetBody (BSTR* Body); HRESULT SetBody (BSTR Body); //get/set Routing data HRESULT GetRoutingOrigin (BSTR* Type, BSTR*Origin); HRESULT SetRoutingOrigin (BSTR Type, BSTR Origin); HRESULTGetRoutingDestination (BSTR* Type, BSTR* Destination); HRESULTSetRoutingDestination (BSTR Type, BSTR Destination); HRESULTGetRoutingException (BSTR* Type, BSTR* Exception); HRESULTSetRoutingException (BSTR Type, BSTR Exception); // send UIMessage w/result values to DestinationRoute HRESULT SendResults ( ); }

[0523] A corresponding IUIMessageDisplay component is an active templatelibrary (ATL) HTML-based control. The UIMessageDisplay is an ActiveXcontrol that leverages the Microsoft WebBrowser control for rendering aUIMessage. UIMessageDisplay applies an XSLT to transform the UIMessagedocument into an HTML-based visualization. The UIMessageDisplay alsohandles user input [which includes various forms of data validation] aswell as submission of the UIMessage back to the engine. The controlsupports the following interface: typedef enum visual_mode {view, edit}eVisualMode; interface IMessageDisplay : IDispatch { // METHODS: //hidden method used by HTML UI to submit entered values HRESULT Submit(); // hidden method used by HTML UI to cancel session HRESULT Cancel( );// clear the HTML display HRESULT Clear( ); // display the current UIMessage in either view or edit mode HRESULT Display([in, optional,defaultvalue(view)]eViewMode Mode); // get the entire UIMessage xmlproperty HRESULT GetUIMessage([out, retval]BSTR* Message); // set theUIMessage xml property of the control HRESULT SetUIMessage(BSTRMessage); // set the current transform property [defaults tostd_display] HRESULT SetUITransform(BSTR TransformName); // allowsloading the control directly with HTML HRESULT LoadBrowserFromText(BSTRHtmlText); // EVENTS: // fired when submit succeeds SubmitSucceeded ( );// fired if result message cannot be delivered to destination routeSubmitFailed ( ); // fired when the HTML Cancel button is clickedSubmitCanceled ( ); }

[0524] As evident in the discussion that follows, in the illustratedembodiment, UI messages are converted to/from XML markup language by theIUI Message component for use (e.g., information display and/orretrieval) by the IUIMessageDisplay component. To facilitate dynamicdisplay of the UI messages, the latter specifies their output to thewebbrowser component active within the runtime client application inXHTML, though it will be appreciated that HTML or other protocols,proprietary or otherwise, markup language-based or otherwise, may beused as well or in addition. Moreover, IUIMessageDisplay utilizes XSL togovern formatting of those displayed message by the webbrowsercomponent, though, again, it will be appreciated that other formatspecification techniques, proprietary or otherwise, may be used tospecify the formatting of UI messages or the elements thereof. Shown inFIGS. 32A-32C is a UI Message schema according to the illustratedembodiment. That schema is presented in XSD format. Shown in FIGS.33A-33B is a UI message template according to the illustratedembodiment. That schema is presented in XSL format

[0525] Turning back to FIG. 30, in step 3010, the action executionthread (AET) instantiates an IUIMessage component for the UI Messageaction associated with a trigger being processed by the AET. In theillustrated embodiment, The message content and other information fromthe production support database 18 b″ is provided to the IUIMessagecomponent in order to format the message (and supporting information) inXML format.

[0526] In step 3020, the AET sets the routing information for theUIMessage. The illustrated embodiment utilizes MSMQ to route messages toruntime clients, though other embodiments may use other protocolsinstead or in addition.

[0527] In step 3030, the AET routes the UIMessage command message—now,in XML format—to the designated runtime client applications. In theillustrated embodiment, which uses MSMQ, this means creating an MSMQmessage of the requisite type and notifying the client application(s)that it is available. In step 3040, waits on the asynchronous responsefrom the runtime client(s).

[0528] To receive a UI Message from the MSMQ queue, the runtime client:

[0529] a) Monitors the RTC Common queue for messages indicating aUIMessage command message type. See Step 3050.

[0530] b) Creates instance of IUIMessage component. See Step 3060.

[0531] c) Converts the MSMQ Message body from VARIANT to string, in thiscase, a string containing the XML encoded message. See step 3070.

[0532] d) Calls the IUIMessage::FromXML (Message) method, passing themessage string. This initializes the IUIMessage component from its XMLrepresentation. See step 3080.

[0533] UI Message visualization is generated dynamically by using an XSLStylesheet associated with the UI Message XML document. A defaultstandard XSL stylesheet, depicted in FIG. 31, provides a table-oriented,HTML-based user interface. To use default (or standard) UI Messagevisualization, for viewing a message, the runtime client:

[0534] a) Creates instance of IUIMessageDisplay control or, moreparticularly, IUIMessageDisplay. See Step 3090.

[0535] b) Calls IUIMessageDisplay::SetUIMessage (IUIMessage::ToXML ( ))to initialize display control. See Step 3100.

[0536] c) Calls IUIMessageDisplay::TransformUIMessage (“std_display”) totransform the Message using built-in transform. See Step 3110.

[0537] d) Calls IUIMessageDisplay::SetMode (view) [view=0, edit=1]

[0538] e) Calls IUIMessageDisplay::Display ( ) to display the UIMessagevisualization. See Step 3120.

[0539] To use default (or standard) UI Message visualization in editmode, the runtime client:

[0540] a) Executes steps a-c, immediately above.

[0541] b) Calls IUIMessageDisplay::SetMode (edit) [edit=1]

[0542] c) Calls IUIMessageDisplay::Display ( ) to display the UIMessagevisualization

[0543] d) The operator enters values for all questions/prompts, thenclick Submit.

[0544] e) Implements an Event Sink for IUIMessageDisplay events. Theseevents are raised by the control to indicate that the user has clickedthe Submit or Cancel buttons on the IUIMessageDisplay HTML form.

[0545] f) If the SubmitSucceeded event was raised then

[0546] a. Call IUIMessage::FromXML (IUIMessageDisplay::GetUIMessage ()). See Step 3130.

[0547] b. Send the UIMessage response back to EventMgr by calling theIUIMessage::SendResults method. See step 3140.

[0548] g) else if the SubmitCanceled event was raised

[0549] a. Put the UIMessage back on the RTC Common queue OR storelocally.

[0550] Overriding the standard UIMessage Visualization is accomplishedon a per-UIMessage basis. The IUIMessage component has a Name property.If the client application has provided a custom visualization forUIMessages that have a specific name, then the client may choose not touse the IUIMessageDisplay control.

[0551] Referring back go FIG. 30, in step 3150, the AET processes anyresponse from the runtime client, e.g., placing back in PDIs or workflowcontext variable any values entered by the operator.

[0552] A further understanding of the interaction between the UIMessagecomponent, the UIMessage display component and the operator is depictedin FIG. 3 and discussed above in connection therewith.

[0553] Thin Client UI Messaging

[0554] UI Messaging for a “thin” runtime client is accomplished asdiscussed above, taking into account the modifications below.

[0555] At the outset, the runtime client of a “thin” client is anMicrosoft ASP.NET application that provides web-based access to UIMessages for web browsers and mobile devices. As above, that applicationprovides a view of the available UI messages for a client, and enablesthe client to enter values for the message items and submit the results.

[0556] Referring to FIG. 34, The UI Message Thin Client consists of twoASP.NET applications. One is a standard ASP.NET web application, whichsupports standard web-based clients. The other is a Mobile WebApplication, which supports mobile device clients. Both applicationswork similarly, the main difference is that the mobile application usesthe mobile controls to support the limitations of mobile devices. Themobile application also does not support custom pages like the standardweb application.

[0557] Startup

[0558] Both applications query the production support database 18 b″ atstartup to determine the common and response queues to use for gettingand returning messages. In order for this to work, the IIS machine mustbe entered as a workstation in the ConfigClient. The WorkstationID forthe IIS machine is also retrieved at this time. This data is stored inthe Application object.

[0559] When a client makes a request for the first time, itsWorkstationID is retrieved from the production support database 18 b″ aswell. If it does not exist in the product support database 18 b″, a-1 isstored. This information is stored in the Session object.

[0560] UI Message List

[0561] When the user requests a list of the available UI Messages(UIMessageList.aspx), the application iterates through the common queue,looking for messages that match the IIS WorkstationID or the client'sWorkstationID. If a message matches, it is added to a table. The name ofthe UI Message is stored as a link to the UI Message editing page(UIMessage.aspx). This link also contains a parameter named ID thatidentifies the message.

[0562] UI Message

[0563] When the user selects a message in the list by clicking on itsname, the application receives the message from the common queue. Thisremoves the message from the queue, making it unavailable to others.This is done using a transaction. The reason for this is that if theuser later cancels the message or never submits it, the transaction canbe aborted and the message will be returned to the common queue wereanother client can pick it up.

[0564] Once the message has be received, it's name is used to check forthe existence of a custom page. If a custom page is found, control istransferred to that page.

[0565] The body of the message is loaded into an XML DOM and then parsedto find the labels, questions, and list PDIs. Appropriate controls areadded to the page to allow the user to enter values for these items. Ifthe item is required and/or a numeric field, a validator control isadded as well to insure the submitted results are valid. The control IDsare set to match the names of the workflow variables corresponding toeach of the message items. This aids in returning the results later.

[0566] The XML DOM, message ID, and message transaction are all storedin the session object for later use.

[0567] If the user clicks the cancel button, the message transaction isaborted, and the message returns to the common queue.

[0568] If the user clicks the submit button, the application parsesthrough the XML DOM finding message items. It uses the workflow variablename assigned to the item to retrieve the value submitted from the form.These values are then set in the XML DOM. Once all of the values havebeen retrieved and stored in the XML DOM, the message is sent to theresponse queue and the transaction is committed.

[0569] UI Message Notification

[0570] A UI Message Notification control was created to provide a way toadd an indicator to a web page that informs the user when a message isavailable. The indicator is a red image when no messages are availablefor the client, and turns green when a message is available. When theindicator is green, clicking on it will popup a new page that containsthe UI Message List.

[0571] Disclosed above are methods and apparatus meeting the objectivesset forth above, among others. It will, of course, be appreciated thatthe embodiments disclosed herein are merely examples of the inventionand that other embodiments incorporating changes therein fall within thescope of the invention. In view thereof, what we claim is:

1. In a method of process, factory-floor, environmental, computer aidedmanufacturing-based or other (collectively, “process”) control, theimprovement comprising: A. executing a plurality of workflows, eachdefining a plurality of actions to be taken in response to eventsoccurring with respect to the process and/or control applications; B.providing, for each executing workflow, data that is common to thatworkflow but not to other workflows.
 2. In the method of claim 1, thefurther improvement comprising configuring a plurality of actions of atleast one workflow to access the data that is common to that workflowbut not to the other workflows.
 3. In the method of claim 2, the furtherimprovement comprising configuring one or more actions of at least oneworkflow to access data that is common to plural workflows.
 4. In themethod of claim 2, the further improvement comprising defining at leastone of the workflows by (i) selecting an icon representing an event,(ii) selecting one or more icons representing an action, and (ii)positioning the selected icons with respect to one another to identifyone or more actions to be taken in response to an event.
 5. In themethod of claim 4, the further improvement comprising associating withthe event associated with a workflow data that is common to thatworkflow but not to other workflows.
 6. In the method of claim 5, thefurther improvement wherein the associating step includes defining asparameters of the event associated with the workflow the data that iscommon to that workflow but not to the other workflows.
 7. In a methodof process, factory-floor, environmental, computer aidedmanufacturing-based or other (collectively, “process”) control, theimprovement comprising: A. executing a plurality of workflows, eachdefining a plurality of actions to be taken in response to a respectiveevent occurring with respect to the process and/or one or more controlapplications that interface with an operator and/or control equipmentfor the process; B. monitoring the process and/or control applicationsand responding to a selected event by generating an event message thatis associated with one of the plural workflows, the event messageincluding data common to that workflow but not to other workflows(“common data”), C. using that common data in connection with executingone or more actions associated with that workflow.
 8. In the method ofclaim 7, the further improvement wherein the generating step includesencoding the common data in the event message.
 9. In the method of claim8, the further improvement wherein the encoding step includes encodingthe common data as name/value pairs.
 10. In the method of claim 8, thefurther improvement wherein the encoding step includes encoding thecommon data in XML format.
 11. In the method of claim 7, the furtherimprovement wherein step (C) includes responding the event message byproviding the common data to a method associated with a name specifiedtherein.
 12. In the method of claim 11, the further improvement whereinthe providing step includes providing the common data as name/valuepairs.
 13. In the method of claim 11, the further improvement whereinthe providing step includes providing the common data in XML format. 14.In the method of method of claim 11, the further improvement whereinstep (C) includes creating a standard template library map with thecommon data provided to the method.
 15. In the method of claim 14, thefurther improvement wherein step (C) includes providing the map to atleast one action associated with the selected event.
 16. In the methodof claim 125, the further improvement wherein step (C) includes usingthe common data by accessing the provided map.
 17. In a method ofprocess, factory-floor, environmental, computer aidedmanufacturing-based or other (collectively, “process”) control, theimprovement comprising: A. executing a plurality of workflows, eachdefining a plurality of actions to be taken in response to a respectiveevent occurring with respect to the process and/or one or more controlapplications that interface with an operator and/or control equipmentfor the process; B. monitoring the process and/or control applications;C. responding to a selected event by generating an event message that isassociated with one of the plural workflows, the event message includingdata common to that workflow but not to other workflows (“common data”);D. invoking a method of an object corresponding to a label in the eventmessage and passing the common data to that method; E. creating astandard template library map with the common data provided to themethod; F. passing the map to each of one or more actions associatedwith the action-trigger object by invoking a method associated with eachsuch action; G. using the common data specified in the map in connectionwith executing the one or more actions.
 18. In the method of claim 17,the further improvement comprising encoding the common data in themessage.
 19. In the method of claim 17, the further improvementcomprising passing the common data in XML format.
 20. In the method ofclaim 17, the further improvement comprising configuring one or moreactions of at least one workflow to access data that is common to pluralworkflows.
 21. In method of claim 17, the further improvement comprisingdefining at least one of the workflows by (i) selecting an iconrepresenting an event, (ii) selecting one or more icons representing anaction, and (ii) positioning the selected icons with respect to oneanother to identify one or more actions to be taken in response to anevent.
 22. In the method of claim 21, the further improvement comprisingassociating with the event associated with a workflow data that iscommon to that workflow but not to other workflows.
 23. In the method ofclaim 22, the further improvement wherein the associating step includesdefining as parameters of the event associated with the workflow thedata that is common to that workflow but not to the other workflows.